Ok - since you asked twice. I'll bit.
Yes, please get on board and use branches along the lines Justin has been explaining.
The practice of branching is very good and I hope to see it catch on for UMA. In addition to being efficient and effective as a work style, consider the accountability, transparency and due process implications of what Justin just wrote:
"Things that are WG consensus should go on “master” (or the appropriate version-tracked major branch), proposed solutions and text by the primary editors should go on branches in the main repository and brought to the group for feedback."
When that feedback loop is tied to enumerated issues things can go smoothly, fairly and very effectively. If the group changes its mind later it is dead easy to roll back the whole project to that moment and have a solid foundation for correcting issues or making different choices. This makes the project easier to be understood by those who are less involved or need to get up to speed later.
The refined functionality for looking backwards and keeping up to speed is reason enough to adopt these practices but the most powerful capability is how this method allows groups of any size to coherently live into their own future. I'm working hard on a legal project now that has a "timeline slider" enabling users to roll the calendar forward and see the expected state of effective law at that date. The law is just another UTF-8 encoded file in just another Git repo and and the text of statutory or regulatory provisions that will have expired (eg "sunset" etc) would not appear in the file. Conversely, the text of currently enacted but not yet "effective" provisions that will have become active by that date will appear in the file. Because the file would exist in a branch designated for a future release of the code - a future version of the legal code. Seeing our current definite agreed state of how an entire code base is planned to look at given time is very very handy. And it seems to be a very very hard thing for most people to conceptualizer or represent with more traditional information organization and representation methods. In fact, people are usually confused about what things, as a whole, are planned to look like at a point in the future and yet many current decisions hinge on just that. This capability of designating branches for future releases affords a high value and highly intelligent capacity for groups to prioritize, sequence and build toward key future decisions.
While only the trusted project leaders should be empowered to make the changes (as Jason indicated) this practice still enables direct access to the best then current thinking and a surface area to make contributions that are best handled now and also contributions that build out or improve major planned or proposed future work. The use of branching for members to make direct contributions is not only democratizing it is also smart allocation of available resources so everybody can actually contribute directly via pull requests. There is a learning curve to this, to be sure, but not an especially big curve.
Given how perfect a fit GitHub (specifically the free, public GitHub service not just the Git protocol) is for consensus document oriented groups like standards organizations and law making bodies I'm increasingly surprised everybody isn't using it and taking advantage of the very basic group collaborative work methods Justin has been describing. GitHub is so fully documented and widely used by technical and non-technical populations at this point it seems that the main obstacle is just aversion to change. That is certainly true in legal circles but just today a City of Boston employee proudly showed be about 20 new and very active GitHub repos in the city's organization including a wide range of projects and types of city workers (even a lawyer). Most of these were still private due to the data or other issues but many are coming online publicly and this trend is definitely sweeping the nation and the world.
I hope to see UMA get with this program.
Thanks,
- Dazza
| Sent from my iPhone
| Please Forgive Typos
_________________
The overhead associated with fully distributed development when there is a clear core team is not worth the headaches it can cause, especially since nobody that I can see would be taking the job of patch integrator to manage all the pull requests. Having an editor create a pull request and then merge it themselves into the main repository is just a waste of that editor’s time.
Only primary editors should have write access to the repository and should be allowed to make changes directly to it. Things that are WG consensus should go on “master” (or the appropriate version-tracked major branch), proposed solutions and text by the primary editors should go on branches in the main repository and brought to the group for feedback.
Non-editors (like myself) can fork the repository, branch, and create either pull requests or simply reference commits and issues from there.
— Justin