For open-source projects that I initiate, I want some way to acknowledge differentiation of roles that permit me to preserve in some friendly way my vision of what is essential for trustworthy development, releases, and life-cycle support. I settled on the idea of being the project Guardian while recognizing there are benevolent dictators, managers, mentors and collaborators with low-friction use of source-code management. For decentralized participation, that means getting my head around guardianship using Git.
Motivation
The open-source projects to which I pay the most attention are little nanoISV projects of my own, where I am almost exclusively the sole developer. Indeed, you are pretty deep into my collegial inner circle if you are aware of any of them.
I also use source-code management for everything. I use it in the development of my web sites. I use it in all manner of software projects, even little throw-away and practice projects of any kind. I’m surprised that I use it so little in other kinds of digitally-born activities, although I do have personal document-management practices.
The Politics of Tools
Source-code management systems do have political leanings with regard to how collaborative development works. With some systems, one can pretty much set up a structure without worrying too much how branching, forking, and working will work, and how various contributions will work. At least, I always thought so.
I have finally had to look at Git with regard to the kinds of project organization that it encourages. Although I am still learning, I have in the back of my mind that Linus Torvalds had his own interests as the total dictator of the Linux kernel in mind when he figured out Git-based collaboration workflows that would allow him to manage all of the contributions that are made to the Linux kernel. It is his model that I am interested in.
Although the idealization of Git is that all of the distributed repositories are equals among many, and this is literally true, there are reasons to have different levels of authority associated with particular public repositories. I recommend the presentation of Linus Torvalds on Git for his views on that subject and how it fits with the practice of curating contributions to the Linux kernel.
Dictator versus Guardian
I am certain that I want to be the dictator. I just don’t like the title. Not even “benevolent dictator.” Dictator doesn’t fit my picture of what a trustworthy collaborative arrangement should look like.
I’ve settled on “Guardian.” I saw that used in a tutorial on Git Workflows as part of Using Git with Visual Studio 2013, and I like it. It works like this.
Decentralized Repositories and Project Roles
There is an official integrated baseline repository. (Sometimes, it is a set of repositories, but we’ll think of that as virtually one collective repository.)
The baseline repository is the master truth of public project artifacts and their history. It may be organized a number of ways, but it is all about that. I also think it is all about how the deliverables of the project are derived, documented, and deployed, whether that is simple or complex. The baseline is backed-up and it can be inspected for the complete project history, of course. And many people can have clones of it that preserve their provenance with respect to the baseline at the point it was cloned. If there is ever need to make a forensic investigation as part of incident resolution, the baseline repository has what’s needed.
Measures to maintain the integrity and provenance of the baseline repository will be appropriate depending on the nature of the project and its artifacts and the level of dependability and authenticity that is to be assured.
New work starts from a baseline. Developers, including contributors, clone working repositories from the baseline repository. They might continue completely independently, basing a fork on the baseline but never expecting to contribute back to the advancing baseline. They could have the clone for testing. They could be developing a fork for any purpose. To maintain future synchronization of the fork with changes in the baseline, they will have a private branch structure that is amenable to merges from the developing baseline.
Contributors have share-back structures. When developers are working on contributions to be made back to the baseline project, they can make their modifications and additions available to the original project in some semi-private manner. This can be via their own repository or a public repository of theirs to which they publish (“push”) their contribution. The contributor semi-private repository could also be a repository/branch of the baseline repository to which the contributor is authorized to push contributions and from which the guardian and any delegates can pull or merge those contributions to a public release. (Casual projects can be without authorization barriers, at least among the few participants of such projects.)
Auditing and accepting contributions. It is the guardian, or delegates (feature managers or leads, say), who pull contributions to their working repositories for verification and integration. Contributors might have pull access to those repositories so they can align their contributions to the result of any adjustments made by the leads. Ideally, leads request changes from the contributors and do not generally do the modifications themselves. This is part of the community spirit of Apache Software Foundation projects, for example. Torvalds has a practice where he does not resolve contribution merge conflicts himself. He requests that the contributor whose contribution exposes the conflict resolve it.
Reconciliation at intermediate staging. The guardian and the leads have whatever arrangement they require for review and developing an integrated view that is pushed to the public base repository. In one approach, the guardian has master development repositories to which changes are merged from the leads (or the contributors where leads are not involved), and the reconciliation is then published to the integrated baseline, which is always collision-free. This must be history-preserving where the provenance and chain of custody back to original contribution must be preserved.
No one is everybody at once. I think the guardian hat should be different than a lead hat. To the extent that the guardian is also a feature lead/manager, those roles should be kept separate. In particular, the guardian hat should not require having to accomplish merge conflict reconciliation. That is a manager/lead responsibility. And, ideally, contributors would already have done that, but for the fact that there may be multiple contributors making changes that may lead to conflicts in the integration of their branches.
Feature-oriented development. If a feature is being coordinated this way, a feature lead might have the only working integration of feature contributions at intermediate times, though. There are ways to keep this public, if only by having the feature-integration repository part of a set of repositories that are the collective integration baseline, with some of them having more ephemeral activity than among release material. This might work for subprojects, too.
This doesn’t square with having all of the truth at a single baseline (or reference) integration all of the time. These concerns are beyond the reach of my personal-computing focus, but scale does seem possible, and I’m satisfied that’s enough to move ahead.
Mentoring is different than managing. In this picture, guardians and leads can also be mentors, although mentors don’t have to be leads or managers. A mentor works with contributors that are new to the project to help them fashion contributions that satisfy the development norms of the project. Mentors are seasoned contributors who work directly with new contributors in having them fashion satisfactory contributions. Mentors have in common with managers the desire for the development and success of the contributor. Mentors can rely on the guidance of leads and the guardian with regard to project direction and process requirements.
Contributors are created equal and not the same. I have been speaking of contributors as developers, new or experienced, who want to be direct contributors to the project and who are or aspire to becoming adept users of the project repository and its artifacts.
Contributions can be casual. Contributors might only be interested in submission of patches or tests or documentation corrections that have pretty low ceremony. Contributors might report bugs and not have the capacity or interest to identify the specific defect and propose corrections. That’s all good. The leads and guardian will encourage and acknowledge such effort in the trustworthy projects I have in mind. Contribution is a precious act to be honored.
Distinguishing the guardian. I think the guardian’s responsibility, at any scale, is to be accountable for the articulation and preservation of the conceptual integrity of the effort and its products.
You can think of the guardian as the chief architect/engineer of the undertaking. The point is where the guardian focuses, something that the guardian should not be distracted from, as happens so easily when immersed in other, nose-in-the-code roles. The same is true for project management, especially for a solo developer or a low- ceremony team. Someone has to keep their eye on the ball and that means not doing anything else at the time.
The Mixed-Blessing of Small Projects
For small projects, guardianship, feature management, mentoring, and contribution will involve the same person(s). It is important, in that case, to have periods of activity when only one of those hats is being worn at a time by any individual. That’s how to ensure that the perspective required of the role is brought to bear without the distraction of other concerns and interests. That applies to the extent that project management roles are required as well.
It can be difficult for a solo developer to switch hats when required. It is valuable to be part of a team that assists its members to keep their hats on straight, whatever the wardrobe of the day happens to be. This can also be aided by colleagues who are not all working on the same project, but who can provide buddy-support.
It doesn’t have to be hierarchical. It is easy to see that guardianship, management, and mentoring are all aspects of leadership roles. In a fluid team, these roles can move around, often spontaneously with little or no ceremony. Specific accountabilities for set periods emerge when scale requires clear points of contact and visible, confirmable process. It’s about structures for workable communication and reduction of friction in achievement of a common purpose.
Repository Versus Project Structure
I was led to this thinking because I am designing a project where Git is to be used as the repository. I don’t think it matters whether a distributed or centralized version-control system is used for management of project artifacts. The philosophies that the different approaches engender are adaptable enough, it seems to me.
On the other hand, Git was designed by someone who wanted loose coupling and flexibility among developers while also providing a way for the benevolent dictator to easily review and accept contributions to a project with very high provenance and artifact integrity. I wanted to understand how Git affords that. This guardianship explanation is what I arrived at for structuring small projects that can scale to full-blown guardian cases as project growth might require.
Orcmid's Live HideOut 