Using GitHub For WP Audio Player

For many, the nicest thing about GitHub is not just the open source nature of the site, but the social aspects of the site. And although I admit I’m not particularly fond of following my friends on yet-another-network, I do enjoy following the status of projects and being able to monitor them.

This morning, I spent some time cleaning up the issues that have rolled in for WP Audio Player. Granted, there aren’t many, but I want to make sure that there’s some organized vision, scope, and plan for the project.

As such, I thought I’d share my method for scoping issues, requests, and bugs as well as how I organize milestones while using GitHub for WP Audio Player.

WP Audio Player Milestones

My Methodology For Using GitHub

There’s nothing terribly complex or new about the way that I’m using GitHub – in fact, I could probably stand to learn a thing or two from others who have more experience than me.

But for now, this is the strategy that I’ve been employing.

Organizing Issues

Before issues become official issues, they normally roll in in the form of blog comments, emails, or repository homepage forum posts. Unfortunately, this causes fragmentation – a topic for another post – so I’ve been trying to keep everything centralized in GitHub.

Overall, it’s worked pretty well; however, some “issues” have included more than a single request or issue.

Just like commits should generally be concise and resolve a single problem, issues should be concise and easily solved by a commit. See the relationship?

As such, I take issues that are several points long and then break them into individual issues.

From there, I triage theme into a milestone. This way, I – and people who are contributing and/or watching the project – can monitor the progress of the project at any time.

Setting Milestones

This is somewhat arbitrary and I’ve even discussed it earlier, and although I’m a fan of doing away with public version numbers, WordPress plugins are not as dictated by releases that are hooked into the core application.

As such, I’m using the following format: X.Y.Z, where:

  • X represents a major version upgrade
  • Y represents a set of resolved issues and/or a new feature
  • Z represents a hotfix

Next, I triage issues into milestones based how I see them fitting into the roadmap. There’s no real rhyme or reason, but I try to organize them into logical steps so that each version builds on the previous, and so that each version is a small set of issues.

I’ll admit that this works far better for smaller projects than larger projects. Case in point, if you look at WP Audio Player, there are five open issues, nine closed issues (some of which are duplicates of the five open issues since I separated the out), and three milestones.

If you contrast that with, say, Standard, then we have 69 open issues, 389 closed issues, and two open milestones with seven closed milestones.

It’s a stark contrast, right? But it goes to show that the methodology employed usually works regardless of the size of the project.

That said, I’m always looking for contributors to WP Audio Player so feel free to initiate a pull request.

Category:
Projects
Tags:

    Leave a Reply

    This site uses Akismet to reduce spam. Learn how your comment data is processed.