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.
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:
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.
Finally I assign issues to each of my 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.
Top comments (2)
This may scare only beginners, people new to github or oss projects, so keep options for beginners & new comers also so that they can contribute easily and don't have to go through long process. But for experienced user this is good, this will help manage the product development easily if it gets bigger and more people start to contribute. Also setup CI for automated testing and PR check.
I have been putting a few items into a backlog project in case anyone wants to contribute but doesn’t want to adopt the methodology.
Will look into some of that automation.