DEV Community: peckjon

Building an AI-Powered Image Search Engine with Daft.ai

peckjon — Wed, 16 Jul 2025 04:25:00 +0000

Image Playground demo using Daft.ai

Back when ML models mainly lived on self-hosted servers instead of smartphones, I spent a few years with Algorithmia, building some of the first and best ML (now "AI") hosting services. Many of my days were spent deep in the trenches with Python datascientists, churning through Jupyter notebooks, optimizing their algorithms to run in ephemeral serverless environments. Those were the days when data transformation pipelines required complex orchestration of multiple tools, custom scripts for every file format, and endless debugging of memory issues and race conditions.

Fast-forward to today: after years focused on DevOps and other areas of software development, I've been itching to get back into data science – and wow, the modern landscape is a revelation. Enter Daft: a distributed Python dataframe library designed to handle complex data workloads with the elegance of Pandas but the power to scale. What caught my attention wasn't just another dataframe library, but Daft's native support for multimodal data processing and SQL-based query capabilities. This felt like the perfect opportunity to build something practical while exploring what makes Daft exciting.

Why Daft is Worth Your Attention

Daft represents a significant step forward in data processing, especially for teams working with unstructured data. Unlike traditional dataframes that treat multimedia as mere file paths, Daft can natively decode, process, and manipulate images directly within its processing pipeline. This means you can resize thousands of images, extract features, or run ML inference – all using familiar dataframe operations that can scale across multiple cores or even distributed clusters.

Structured data gets an upgrade, too! Daft's built-in support for SQL queries works across nonrelational data, such as JSON... so those of us who grew up writing SQL92 feel just as comfortable querying a wide variety of formats.

The three Daft features that really shine in this project are:

🔍 Image Discovery & File Processing: Using daft.from_glob_path(), we can recursively discover image files across directory structures with built-in filtering by extension. No more writing custom directory traversal code or managing file system complexity.

⚡ Bulk Image Processing: Daft's native image operations let us chain .image.decode(), .image.resize(), and .image.encode() in a single pipeline. This means processing thousands of photos happens in parallel without having to manually manage Pillow operations, threading, or memory concerns.

📊 SQL Query over JSON: Once our image metadata is processed, Daft's SQL interface daft.sql() lets us write SQL queries directly over our JSON data structures, including complex operations that replace slow and cumbersome dataframe operations -- like array explosions for tag searching, and querying across multiple fields simultaneously.

Building the Demo: Where Theory Meets Practice

This image search tool demonstrates how these capabilities come together. The application discovers images in local folders, processes them through AI models for automatic captioning and tagging, then creates a searchable web interface. Here's where Daft eliminated entire categories of complexity:

No manual file system traversal – Daft's glob patterns handle recursive file discovery: image_processor.py#L40
No individual image resize operations – Daft's bulk image pipeline processes everything in parallel (no sequential Pillow operations!): image_processor.py#L135
No complex JSON parsing for search – SQL queries over structured data feel natural and performant: app.py#L95-L106
No manual parallelization – Daft handles efficient resource utilization automatically: image_processor.py#L132

The result? Clean, readable code that focuses on business logic rather than infrastructure concerns.

Development Notes & Caveats

Full transparency: while the initial code generation was aided by GitHub Copilot and Claude Sonnet 4 (you can see the original prompt in PRD.md – itself pair-generated with Copilot's help), the real work happened in the development iterations. AI tools are incredibly powerful accelerators, but they work best when guided by an experienced developer who understands the problem domain and can refine the generated solutions.

Important: This is a demo application only and should not be used unmodified in a production environment. It may contain security vulnerabilities and is optimized for simplicity and compatibility, not efficiency. For example, the BLIP model used for image captioning is a few years old and not state-of-the-art – I chose it for its reliability and broad compatibility rather than cutting-edge performance.

This project showcases only a tiny slice of Daft's capabilities. The framework supports everything from distributed computing across cloud infrastructure to advanced ML workloads with GPU acceleration. If you're dealing with large-scale data processing, multimedia pipelines, or looking to modernize your data infrastructure, there's a lot more to explore.

Ready to dive in?

🚀 Jump right into the code or read the detailed implementation guide below!

Features

🔄 Data Loader

Folder Processing: Select any local folder containing images
Recursive Discovery: Automatically finds images in all subfolders
AI-Powered Tagging: Uses BLIP model for automatic image captioning and tagging
Batch Processing: Efficiently processes large image collections using Daft.ai
Progress Tracking: Real-time updates on processing status

🔍 Image Library

Smart Search: Search images using natural language descriptions
Tag-Based Filtering: Find images by automatically generated tags
Visual Preview: Grid view with hover effects and click-to-expand
Detailed View: Modal with full image, caption, tags, and metadata
Responsive Design: Works on desktop and mobile devices

Quick Start

Prerequisites

Python 3.9 or higher
4GB+ RAM (for AI model)
Modern web browser

Installation

Clone or download this repository
Run the setup script:

   chmod +x setup.sh
   ./setup.sh

Start the application:

   source venv/bin/activate
   python app.py

Open your browser to: http://localhost:8000

Usage Guide

Processing Images

Go to the Data Loader page
Enter your image folder path (e.g., /Users/yourname/Pictures)
Click "Start Processing"
Wait for completion - the first run will download the AI model

Example folder paths:

macOS: /Users/yourname/Pictures/vacation
Linux: /home/yourname/photos
Windows: C:\\Users\\yourname\\Pictures

Searching Images

Go to the Image Library page
Enter search terms like:
- "dog" (finds images with dogs)
- "outdoor" (finds outdoor scenes)
- "person" (finds images with people)
- "mountain landscape" (finds mountain landscapes)
Click on images to see full size with details

Technical Architecture

Backend (Flask)

REST API for image processing and search
Job management for long-running processing tasks
File serving for processed images

Data Pipeline (Daft.ai)

Efficient file discovery using glob patterns
Parallel processing for image operations
Memory-efficient handling of large datasets

AI Processing

BLIP Model: Salesforce's BLIP for image captioning
Automatic Tagging: Extracts objects and scenes from captions
Standardized Output: Consistent 224x224 processed images

Data Storage

{
  "images": [
    {
      "id": "abc123",
      "filename": "photo.jpg",
      "original_path": "/full/path/photo.jpg",
      "processed_path": "photo_abc123.jpg",
      "file_size": 1024576,
      "created_date": "2025-07-14T10:30:00",
      "tags": ["outdoor", "landscape", "mountains"],
      "caption": "A beautiful mountain landscape",
      "processed_date": "2025-07-14T15:45:00"
    }
  ]
}

Supported Image Formats

JPEG/JPG
PNG
GIF
BMP
WEBP
TIFF

API Endpoints

Method	Endpoint	Description
POST	`/api/process`	Start image processing job
GET	`/api/jobs/{id}`	Get processing job status
POST	`/api/search`	Search images by text
GET	`/api/images`	Get all processed images

File Structure

daft-image-playground/
├── app.py                 # Flask application
├── image_processor.py     # Core processing logic
├── requirements.txt       # Python dependencies
├── setup.sh              # Setup script
├── LICENSE               # MIT License
├── templates/            # HTML templates
│   ├── data_loader.html
│   └── image_library.html
├── data/                 # Generated data files
├── processed_images/     # Resized images
└── README.md

Performance Notes

First Run: Model download may take 2-5 minutes
Processing Speed: Varies by hardware and image size
Memory Usage: ~2-4GB during processing
Storage: Processed images are ~50KB each (224x224 JPEG)
Model Size: ~1GB

Troubleshooting

Common Issues

"Model download failed"

Ensure internet connection for first run
Check disk space (model is ~1GB)

"Permission denied"

Ensure image folder is readable
Use absolute paths, not relative

"Out of memory"

Process smaller batches
Close other applications
Consider upgrading RAM

"No images found"

Check folder path is correct
Ensure folder contains supported image formats
Verify folder permissions

Logs and Debugging

Processing logs appear in the terminal
Check browser console for frontend errors
Job status API provides detailed error messages

Development

Interested in taking this further? A few suggestions:

Custom Image Models:

Replace BLIP model in image_processor.py
Modify tag generation logic

Search Improvements:

Add vector similarity search
Implement advanced filtering

UI Enhancements:

Add sorting options
Implement image collections

Dependencies

Daft.ai: Distributed data processing
Transformers: Hugging Face model library
Flask: Web framework
Bootstrap: UI framework

License

This project is licensed under the MIT License - see the LICENSE file for details.

MIT License allows you to:

✅ Use commercially
✅ Modify and distribute
✅ Place warranty
✅ Use patents

The only requirement is to include the original copyright notice.

Need Help? Check the troubleshooting section or create an issue on GitHub.

A checklist and guide to get your repository collaboration-ready

peckjon — Wed, 18 Sep 2024 18:44:15 +0000

Want the TL;DR, or you’ve already been using GitHub for a while? Skip to the end for a printable checklist that you can use to ensure that you’ve covered all aspects of making your repository collaboration-ready.

My daughter has a pair of pet gerbils. They’re awesome, but not the most complex creatures to care for. They need their cage cleaned occasionally, their food and water refilled, and may need a neighbor to check in on them if we’re away for a while. But someday, she may have a pet that requires more care and attention–a cat or dog perhaps, which needs to be played with and nurtured every day–so she’ll want to have a few good friends who know her pet and can be their companion whenever she’s away. And someday, she may even have a child of her own, making her connections to community and family ever more important. As the saying goes, it takes a village to raise a child.

So it goes with code projects. My colleagues and I often refer to our projects as “pets” or even “children” (sometimes jokingly, sometimes obsessively). We pour a lot of our own care and attention into them, but it can be easy to forget how important the community’s contributions can be to their success. In the world of software development, collaboration can make the difference between a brittle last-minute release and a reliable, maintainable, pain-free project. Whether you’ve been coding for a day or a decade, your colleagues are there to help strengthen your work. But they can only help if you’ve given them the tools to do so.

Your primary responsibility as the creator or maintainer of a repository is to ensure that others can appropriately use, understand, and even contribute to the project. GitHub is here to support that mission, but ensuring that a repository is collaboration-ready takes a bit more effort than using git clone. So read on to learn the settings, content, and behaviors that will help you succeed.

1. Repository settings

The settings of your repository lay the foundation for collaboration. They determine who can see and contribute to your project, how contributions are reviewed, and what happens to those contributions once they are submitted. Properly used, they can foster an environment in which contributors across the globe will find, make use of, and help build your project. In a corporate setting, they help shift developers from a siloed way of thinking and building to a “search-first, collaborate-first” mindset. This practice, known as innersourcing, reduces redundant work and accelerates the whole company.

Visibility

You’re aiming to maximize contributions and reuse, but that doesn’t always mean making your repository public, especially in a corporate setting where information privacy is a consideration. You have several options available in the “Settings” tab of your repository.

Public lets anyone in the world see and copy your code, and generally allows them to create issues or pull requests, so they can provide feedback about whether it works well, or even suggest (but not force) changes to improve it. This is generally great for personal projects containing no protected information (those tokens are all stored separately, right?) but only for certain “blessed” company projects.
Internal is a special visibility level used by GitHub Enterprise, allowing anyone inside your organization to see the repository, but nobody in the outside world. We generally suggest this as the default level for company projects that don’t have siloed sensitive information (such as customer-specific data or logic that only a specific group should know about).
Private is the most restrictive option, and can be a collaboration-killer. Use this option sparingly, and if you do, be sure to invite some collaborators.
Collaborators are specific individuals or teams you invite to be part of your project. They can be given specific roles such as “Read” (allowing them to see your otherwise private repository), “Write” (letting them directly commit or manage pull requests), “Admin”, and many others.

Protect the main branch

While you want to maximize the number of people who can see and contribute to your project, you still need to ensure that their contributions are properly reviewed, both by your core team members and by automation. In most cases, you’ll want to create a repository rule (the modern replacement for branch protection) on your main branch and configure it to require a pull request before merging is allowed. By requiring at least one approver, ideally one from your CODEOWNERS file (discussed in the next section), you’ll guarantee that another human reviews each set of changes. In addition, you will want to have automated tools such as unit tests run against each pull request; these are known as status checks and will be covered under “Automation and checks” below.

2. Repository contents

Software projects don’t just consist of code. Your repository should act as a guide to collaborators, letting them know why it exists, how to use it appropriately, and the best ways to contribute. Adding a few key files (generally written using Markdown) will help other people discover your project and understand how to collaborate effectively.

README.md: This is the first file visitors to your repository will see, so it is critical to include in your repository. It should describe what your project does, how to use the repository, and any configuration needed. Additionally, a good README includes the mission of the project, what it aims to do, and why it exists. Lastly, be sure to describe how and by whom the project is maintained.

LICENSE.md: A license file defines what others can and can’t do with your code and other content. Whether your goal is to allow unrestricted use of your project, or to add special restrictions on its usage and distribution, it’s crucial to include a license. Visit choosealicense.com for guidance on which license might work best for your project, then add one to your repository.

CONTRIBUTING.md: You can reduce the amount of confusion and friction that potential contributors (and you) face by clearly defining why and how others can contribute new code, documentation, art, or other elements to your project. If the contribution steps are very simple, you might just include them in your README; but, if you find it takes more than a paragraph or two (and it usually does), it’s best to create this separate file. It should include information about the types of contributions you’re looking for, how to propose a new feature or bug fix, the process for submitting pull requests, and any specific coding standards or style guidelines contributors should follow. For a good example, take a look at the contributor guide from GitHub’s docs project.

CODEOWNERS: A CODEOWNERS file assigns one or more users who will be responsible for code in a particular part of your repository. As specified in the repository settings, these individuals will be automatically requested for review when someone opens a pull request that modifies code they own. Note that this file, unlike the others mentioned here, should not have the “.md” extension.

CODE\_OF\_CONDUCT.md: A code of conduct establishes the social norms, rules, and responsibilities that participants in your project should follow. It promotes a friendly and respectful environment for collaboration, and it is easy to add manually or by using one of GitHub’s templates!

With these files in place, your repository will be much more approachable and understandable, and you should start seeing contributions flow more freely. But if you want to go even further, there’s even more you can do to set up your project for healthy contributions.

3. Automation and checks

It’s time to enter the Matrix. As Agent Smith is fond of saying, “Never send a human to do a machine’s job.” While you generally want at least one human reviewer for each major change, you should make their job as easy as possible. GitHub’s built-in automation and CI/CD system, GitHub Actions, allows you to run workflows in response to file changes, pull requests, external triggers such as chat tools, and even cron jobs. Let’s look at a few ways this can make collaborators’ lives easier.

Linting

Linters are tools that analyze code to detect various types of errors and enforce a consistent coding style. Incorporating linters into your development process can greatly improve the readability and quality of your code, making it easier for others to understand and contribute to your project. One of the most popular is Super-Linter, which can be initially configured in a single cut-and-paste step.

Building and testing

While the exact compilers and test suites you run will be specific to the language and framework of your application, most can be executed automatically in your repository. To find the right ones, search through GitHub Marketplace’s list of Build and Test Apps & Actions, then follow the instructions specific to your preferred tool. Or, execute them by running command-line scripts and arguments in your GitHub Actions workflow.

Checks

When information is surfaced to reviewers right inside the pull request, it makes their job faster and easier, eliminating the need for them to manually run test suites or run through a physical checklist. If the automated checks fail, you can even block deployments from going out the door. Once you’ve added a linter or test suite as described above, and it has run at least once, consider configuring it as a status check in your repository settings. This will help ensure that your app is properly tested each and every time a pull request is created.

This is not a complete list, but every project is different, so also consider what other code quality, dependency management, or pre-release automation you might want to include. Then, consider how you want to deploy the project. In most cases, you’ll find there is a component in the GitHub Marketplace that provides turnkey integration with your favorite infrastructure provider, but it’s also possible to write your own GitHub Action to deploy your app after all the checks have passed. And, for high-volume enterprise projects, consider using merge queues if you start getting traffic jams on rapidly changing branches.

With these automation tools and checks in place, you can have more confidence in the quality and consistency of contributions to your repository and spend less time manually managing the process.

4. Security

Security is a paramount concern in any software project and is especially important when including a variety of collaborators who may have different levels of security training (or none at all). Fortunately, there are a few simple steps you can take to protect your code, data, and users from potential threats.

Roles

Carefully decide which roles, and thus permissions, you give to collaborators in your repository. Generally speaking, you’ll want to assign the “Read” role to the general public. “Triage” and “Write” are for trusted individuals such as members of your company or working group (but only once protected branches and checks have been set up). “Maintain” and “Admin” roles are best for your core maintainers, who are responsible for reviewing and managing what goes into production. Also consider that “Triage” and above have the ability to manage issues, discussions, and comments–so you’ll want to trust that they have the commitment and background to manage the flow of metadata surrounding your project. Enterprise customers can take advantage of custom repository roles for more granular permissions control.

Secrets management

Secrets are sensitive data like API keys, passwords, and certificates that you need to keep private. You don’t want these to be directly embedded into your code or your logs; instead, you should use either a third-party keystore or GitHub’s native secret-management tools, which can be found under the “Secrets and Variables” section of your repository settings. There, you’ll find separate sections for GitHub Codespaces (a tool described in the “Advanced Options” section below) and for GitHub Actions, because you may want to use different secrets during development than you do in production.

Security scanners

Scanning code for vulnerabilities is a complex topic, but breaks down into three major categories.

Dependencies: 80-90% of most applications’ code comes from third-party sources–the frameworks and packages we build the rest of our code on top of. GitHub Dependabot is available on all public repositories, and can be automatically enabled across entire organizations. It is able to alert you (and help provide a fix) whenever an insecure dependency is found. To ensure that Dependabot is running, check the “security” tab at the top of your repository. You can also enable dependency version updates to let you know when new versions of packages are available, so you can keep up-to-date even if an explicit vulnerability has not been identified.
Secrets: While you should already be using a secret manager as described above, we all make mistakes, and some tokens may slip through the cracks and get embedded directly into code. Secret scanning tools, provided both through third-party integrations and via GitHub Advanced Security for Enterprises, can notify you about or even block secret tokens as they are pushed into your repository.
Novel Vulnerabilities: As you write new code, you may accidentally add new vulnerabilities, either in the novel code itself or in the way you wire together existing components. There are a wide variety of ways to scan your overall application, some of which are language-dependant. Enterprises can also rely on GitHub Advanced Security’s code scanning to find a wide variety of flaws, from SQL injection to circular references, in most popular coding languages.

SECURITY.md and private vulnerability reporting

If a user or security researcher identifies a problem with your project, they need to know how to securely and responsibly report it. Include a security policy file in your repository to provide these guidelines and to help maintain the trust of your users and the wider community. Also turn on private vulnerability reporting; this allows security researchers to securely report any vulnerabilities they find!

5. Advanced options

Beyond the basics, there are a number of advanced options you can leverage to further enhance your repository’s collaboration readiness.

Issue templates

As collaborators make use of your project, they will file issues asking for bug fixes and enhancements. By default, these requests will be fairly unstructured, and you may need to loop back to the creator several times to get all the information you need. By creating a few issue templates, you can provide guidance, define which required and optional fields users will see, and set up specific options they’ll select when opening issues.

GitHub Codespaces configuration

GitHub Codespaces provides a complete, configurable dev environment on top of a repository. This allows anyone to work on your project from anywhere, without having to set up a local environment. Providing a well-configured codespace can make it much easier for others to contribute to your project and makes the project less brittle, since all developers will be working from the same configuration (eliminating the “it works on my machine but not yours” problem).

Environments

GitHub Environments let you specify where certain tasks (like deployments) should happen. They can be configured with specific protection rules, ensuring that important tasks only happen in a controlled and secure manner.

6. Next steps

Now that you’ve set up your repository, it’s time to consider the broader aspects of collaboration, including your role as a maintainer and how you engage with your community.

Responsiveness

As a maintainer, your responsiveness plays a crucial role in fostering a healthy, collaborative environment. This involves promptly addressing issues and pull requests, providing feedback, and guiding new contributors. Set aside specific times each week that you’ll dedicate toward responding to changes and remediating problems. If you want to measure how responsive your project is, check out the Metrics Action.

Project management

GitHub’s native project planning capabilities are usable both for individual projects and enterprise-wide collaboration. Set up GitHub Projects to manage your work and provide visibility to your community. This not only helps you stay organized, but also allows others to understand the current status of the project and where they can contribute.

Visibility

A well-maintained repository is of little use if nobody knows about it. Promote your project through blog posts, demos, or even dedicated project portals. The more people who know about your project, the more potential contributors and users you can attract.

Community engagement

Engaging with your community is key to fostering a healthy, collaborative environment. This might involve organizing meetups, running a project blog, or even just actively participating in discussions.

By following these standards, you can ensure that your repository is not just collaboration-ready, but also a place where a vibrant community can flourish! Print out this checklist, and use it to help guide you along each time you create (or revisit) a GitHub repository.

Get started

Download this printable checklist that you can use to ensure that you’ve covered all aspects of making your repository collaboration-ready. Or, use this handy Issue Template to create an updatable checklist right inside your own GitHub repository!

New year, new planning habits: using GitHub Projects to track your goals

peckjon — Tue, 20 Feb 2024 17:24:13 +0000

At the beginning of every year, I do the same thing: resolve to get myself fitter, learn a new language, and build out that awesome new side project. And at the end of every year, I do the same thing: look back on my unfinished goals, and regret my failures. This year will be different. It's time to break the cycle, to build out specific and actionable plans, to itemize and track my progress… in other words, to do proper project management. And since my team lives in GitHub every day, I thought I'd use the opportunity to see if I can use GitHub Projects (the tool we use for all our planning and tracking) for my own self improvement, to manage my new year's resolutions!

Getting started is always the most difficult part of any project, and while I could build out my project from scratch, I have the option of starting from a template instead. There are two kinds of templates to choose from:

Organization-level templates can be created by any org member with the right level of access. These are great for standardizing our project management practices, can be created from scratch or converted into a template from an existing project, can have preconfigured views, workflows, custom fields, and more.
Built-in templates, provided directly by GitHub, are a good starting point for generic projects. In this case, I don't need something that'll fit a specific organizational standard, and this is more of an ongoing planning project than a specific feature release, so I'm going to pick GitHub's "Team Planning" template and get started!

Even though this isn't a typical team-oriented project, it's clear that there are a lot of views and options that will be useful. But before I start exploring all the possibilities, I'll start by adding a few items to the project. Some of my new year's resolutions are conceptual, like "eat better" or "practice speaking Spanish", and they don't connect to any existing code or repositories. That's fine – GitHub Projects allow me to rapidly hand-enter any text and immediately turn it into an item!

However, some of my resolutions are related to existing repositories that I'm already working on. For these, I have a few options. I can type '#' while adding an item to get a list of repositories I'm connected to, pick one, then select any issue or pull request to add.

For ongoing projects, though, this will get tedious; I don't want to manually add every Issue in my repository. Fortunately, GitHub Projects has a concept of Workflows: flexible and graphically-configurable automation which can react to changes in items, related repositories, pull requests, and more. Among other options, this means I can easily configure a workflow to notice whenever an issue is created in my repository, and immediately add it to the project.

Now that I have a few items, I can start thinking about how I want to visualize my work. A Project can have as many different views as I want, each represented by a tab at the top. And each tab can have a different layout, "Board", "Table", or "Roadmap". The template I used has examples of each, the first being my Backlog, shown as a simple Kanban board. I'd like a little more granularity though, so I'll click the '+' to add another column.

I could go a lot further with this, filtering items by type or label, adding swimlanes, or even changing what field is used to define the columns. But for now, I'll simply drag a few items into my new "Up Next" column, then take a look at another view: "Team Capacity". This is a great example of using a Table layout to summarize information. By summing the effort estimates I've placed on each work item, then slicing the view by Assignee, I quickly see who might be overburdened and who has capacity for more tasks. In fact… there may be something I can offload to free up a bit of my own time! I bet my friend @geektrainer has a decent salad recipe he's willing to share, so I'll click on that item and assign that to him. My view immediately updates to show the rebalanced tasks.

This is great, but it's also just a single point-in-time. I know from experience that taking on all my resolutions at the same time will be a disaster (ask me sometime about the emotional load of taking on a new job while going keto during dry January)! Instead, I want to plan out my tasks over the next few months. For that, I'll use Iterations, which allow me to create and assign named date ranges. I prefer thematically-named two-week sprints, so I'll use "Attitude" for Jan 1-14, "Balance" starting Jan 15, "Commitment" for the next, and so on. Clicking on the Roadmap tab, I can now easily visualize what I'll be working on this quarter.

There are lots of ways I could keep improving this Project! I might want to…

add a new view (perhaps a "Triage" table to help me see new tasks that have just come in, then assign priority and effort estimates)
create some new custom fields containing text, numbers, or a list of options (e.g. a "focus area" with options "social", "emotional", "physical")
add column limits so I'm not overwhelmed with too many items at once
create custom filters so each of my collaborators has a personalized view

But for now, I want to help ensure I stay on track, and one of the best ways to do so is to make my efforts publicly visible. By inviting a few friends to my project, I can take advantage of a great new feature: status updates. First, in my project's settings, I'll click into "manage access" and invite @scubaninja – she's great at motivating me to get work done!

While collaborators can always choose to get notifications about individual issues if they desire, I want to go beyond this with regular, handwritten summaries. I'll treat this a bit like a newsletter or point-in-time update on the project. While there's no set format for updates, I can use rich formatting and generally will want to include:

high level details about how the project is currently going
any relevant KPIs/metrics
details on any recent successes or misses
celebration of contributors' work (using '@' mentions)
potential risks or upcoming challenges

This exercise has been great for kicking off my own personal goals, but I'm even more excited to see how teams everywhere will use GitHub to initiate, standardize, maintain, and iterate on their collaborative projects. Whether you're just beginning, migrating from another project planning platform, or investigating our newest features, I urge you to try creating and using organizational templates, adding a project to your existing repositories, and customizing your existing projects to include new views and custom fields. With the power of GitHub Projects at your fingertips, you'll be crushing it in no time. Get started today!