Project and people management
‘agile’, the easiest way
Organize sprints
- Plan the month-long sprint at the very start of the month, organize a gathering with whom you usually work the most either over voice or IRC or whatever communication channel is acceptable to all, and finalize on what you all would like to work on the month.
- Tag the issues individually you would like to handle during the sprint using the defined format “Sprint: January 2013” so that is a consistency in terms of format across all initiatives. It is recommended that you don’t start a new issue in the current sprint once it’s in progress, unless there is something exceptional and critical.
- One of the important factors is the manpower. So, talk to a group of competent and enthusiastic professionals and effectively convince them to dedicate themselves for the sprint and finally get the work done !
- By the end, start again from planning the sprint for the next month and deciding what should be the to-do-list in terms of handling the pending issues. The pending issues wouldn’t be necessarily from the backlogs of the previous sprint, eventually, it may also consist of the new issues you tag in yourself and for your group.
- It is always recommended that you have Sprint retrospective meetings and review what went and didn’t go well in the previous sprint so as to learn for the next set of issue and continually improve the process.
- By the end of each sprint, you should make sure the new functionality are ready for demo (recommended) or to pass through the 'gates' to commit to the master branch of the chunk of your initiative.
How to find and keep contributors/volunteers
- Make sure your g.d.o group is up to date and has some consistent activity. Make sure, your g.d.o is up-to-date and consistent activity is reflected.
- Make the most of your twitter account to get better visibility and stay connected. If you don’t have a twitter account, just go for creating it.
- Publicize the events and your activities online by all possible and acceptable means, preferably with Drupal.org frontpage posts.
- Don’t forget to clearly document the easy ways for people to get involved in the contribution.
- Organize a weekly meeting (if not daily) on IRC, so as to find more contributors and volunteers as helping hand.
Issue tracking and project workflows
‘Sprints’ (or Iterations) and ‘Phases’
- Plan your sprint small initially so as to ensure completion of the same within the defined timeline and to avoid people getting discouraged.
- If you feel you wouldn’t be able to complete within the timeframe (ie. 1 month), just fragment it into chunks of sub-issues.
- You may also fragment the functionality into few phases incase the functionality you are working is larger enough to take more than one sprint.
- 'Doing so will make merging back into the master branch much easier !'
‘Gates’ ???
‘Gates’ are the validation stages through which each and every core change needs to pass through, so as to ensure the quality is up to the standards. They are also marked as a ‘checklist’ that are used to evaluate the readiness of the patch by both developers and patch reviewers/core committers.
You may Click here to know more about how a gate works and is defined.
Code and git
Sandboxes
Types of Sandbox
One sandbox - All codes are in one place and separate projects are into branches. The issues are all mixed up in a single queue.
Multiple sandboxes - The issue queues are fairly isolated, However, the code is scattered into chunks which make one tougher to get the overview of the entire initiative. Even, the professionals working on such multiple chunks need to jump all around.
Please note: Possessing One sandbox per initiative is always recommended.Working with git
Branch Nomenclature
Create a branch with a meaningful name that includes the version (aka 8.x-uuid).
Initial setup
Take a clone of drupal core git remote add git push 8.x
The upcoming steps would depend upon the workflow. Every initiative will have atleast one feature branch.
git checkout -b -8.x git push
General idea behind this is to merge as little as possible, providing a meaningful commit message so that when it gets merged upstream back to the core, the commit log is not populated with ‘Merge from’.