Project Management Lifecycles for Personal Projects

ignoreintuition

Brian Greig

Posted on October 8, 2018

Project Management Lifecycles for Personal Projects

I have started a few OpenSource projects in my web development career. In that time I have had varied level of success with features, maintenance, and defect management. Having always felt that creating a proper project was overkill meant that none of them followed a conformed standard. On my current project v-chart-plugin I experimented with following an Agile management methodology. As I walk through the workflow below I am curious what levels of success others have had. Please share in the comments below.

Overview of the project

Just to give you a sense of the size / scale of the project: This is a customizable Vue component plugin for adding charts and graphs bound to Vue's reactive data. The plan is to have about a dozen or so charts with multivariate support, goal tracking, customizable widgets (labels, titles, etc) and additional customization via CSS and the API.

I began the project about a month ago and I am currently in the 0.1 pre-alpha stage with 0.2 alpha planned for November 2018. Currently I am the sole contributor but I have been actively looking for others. Long term the expectation is a stable plugin would allow for contributors to integrate their own graphs using the API. Those graphs could be included in future releases extending the library of total charts available.

The project

Starting the project I decided to follow some basic Git best practices. This meant no pushing directly to Master, all features would have their own unique branches, and all new code would be merged via PRs in Github. To organize these I created an issue in GitHub for each bug, feature, enhancement, etc and labeled them accordingly. I also created some backlog / tech debt items (such as general optimization, error handling, documentation) for those type of tasks. Those are labeled accordingly as well.

issues

Any time I began work on a new feature I would create a branch in Git with the name issue-{x}-{short-description}. From here I end up with a series for branches that look like this:

branches

I can then work on each of those branches individually occasionally merging the changes back in from Master when other features are completed. They can then be pushed back up to origin when the feature is complete and merged into Master via a PR in Github

To manage the project I have broken it up into Sprint Milestones with larger projects that consist of three two-week sprints each.

Projects

Finally I assign issues to each of my sprints.

sprints

This allows me to set deadlines for each of the features and keeps me on task to deliver features and close issues. So far it has been working well allowing me to focus on a single feature or bug without being overwhelmed with all of the open items. It has also allowed me to push out changes fairly regularly. My concern is, as the project gets bigger and potentially more people start working on it, is this going to scale. Will it also deter people from contributing because of the added process around changes or is this type of workflow a welcome addition.

💖 💪 🙅 🚩
ignoreintuition
Brian Greig

Posted on October 8, 2018

Join Our Newsletter. No Spam, Only the good stuff.

Sign up to receive the latest update from our blog.

Related