@burke, how would you like to approach this? We have some criteria listed on the Dev Stages page, a few of which they fulfill, some of which they don’t.
The other approach we’ve talked about about is that a /dev/4 can vouch for raising new /dev/4s, and @shruthidipali is a /dev/4, so she’s effectively doing this. Do you want to document a process for this? (I’m also happy to vouch for them myself.)
@dkayiwa, @wyclif, @raff, do we have any documentation about “now that you’re a /dev/4 you have push access to openmrs-core, here’s what you need to know”?
The closest to that is probably the “Criteria” and “Expectations” column. It might be good to add to the that page some narrative descriptions for each of those activities that give a bit more detail and/or links to other documentation about those activities, so people can easily figure out how to get up to the /dev/4 (or whatever) level.
Then again, what @darius mentioned regarding the process is still important to figure out, and how that nomination process relates to the criteria & expectations.
Bahmni is doing Order Entry work in Platform 1.12 (and the OpenMRS Community has empowered them to do this). Bahmni Tech Leads want to be able to merge PRs from their team members (without needing to wait for Wyclif, Daniel, and Rafal, and also without needing to overburden them)
Practically, this is the only piece of /dev/4-ness that the Bahmni team urgently needs
Empowering Bahmni and others to develop openmrs-core faster is good for OpenMRS. The best strategy for OpenMRS to expand its dev and code review capacity is by enabling/empowering groups of people to work on areas like order entry (and they need to be able to push code to be able to do this). Like the linux lieutenant model.
As-written, the /dev/4 criteria are too limiting, IMHO. Do we really think that a Bahmni tech lead needs to have “publicly thanked at least 10 other devs” or else they’re not allowed to push to openmrs-core? That seems to be shooting ourselves in the foot.
So, my proposal is:
Lower requirements for being able to push to openmrs-core (especially for someone working in a specific code subsection of code, which we can manage socially, not by complex permission schemes)
Explicitly document our expectations for code review in openmrs-core, and the behaviors we’d expect e.g. from Vinay merging a PR for another Bahmni dev. For example:
specific code conventions to look for
needing a ready-for-work ticket for non-trivial work
expectations on back- and forward-porting
Also explicitly invite people to step into a bigger role outside of just a specific code area (“Order Entry in Platform 1.12” in this case).
The listed expectations & privileges on the Developer Stages page are there to help people understand & frame where they (or someone else) belongs in the spectrum of development stages of engagement. It’s not just about privileges and github access. In fact, to me, the true litmus test are the categories of “learning” → “contributing” → “cooperating” → “collaborating” → “leading” and that people’s behaviors fit within the spirit of those categories. For example, if someone is making great contributions, but focused solely on meeting their own needs, they’re a /dev/2; if they’re coordinating their efforts with others in the community, then they’re behaving as a /dev/3; if they are not just coordinating with others in the community, but taking on the responsibility of ensuring that their work is aligned with community needs and helping others coordinate their activities (wearing an “OpenMRS hat” at times), then they’re behaving as a /dev/4.
I think anyone can vouch for anyone (a GSoC student could point out that their mentor is behaving more like a /dev/4 than a /dev/3), but gaining trust of /dev/4s & /dev/5s would obviously carry weight. For now, I’d like to maintain the /dev/5 group as the caretakers of the staging process (both adjusting stages and holding regular reviews/QI on the entire process). To this end, a /dev/4 requesting someone else become a /dev/4 is always welcome, but I’d want a /dev/5 (like yourself) to sponsor (i.e., be aware of and in support of) the change.
Now to the specific question…
@darius is the /dev/5 closest to the team, so I’m happy to let him make the call. From my standpoint, given my thoughts above, I would approach it this way:
A /dev/4 functions in the interface between their organization and the wider OpenMRS community. They don’t just help get their code into the community, but regularly interact with devs from other organizations in the community to ensure design & code changes are having general benefit and not harming other orgs. Someone behaving as a /dev/4 might consider leading or helping lead the community development swim lane or taking on a PR that has nothing to do with meeting their organization’s needs.
A /dev/3 is focused primarily on the needs of their organization or advancing a speciific feature or module and would work in conjunction with the community as needed to get that feature or module incorporated into the community. A /dev/3 might lead a sprint or even help get out a release, but would be less likely to take on tasks for the community that aren’t related to their organization’s needs.
Surely there are (and will be) more /dev/4s in the ranks at Thoughtworks and we want to recognize and encourage finding more. But, if we have people working as /dev/3s, but needing to push to core under specific circumstances, I’d rather grant push access to all /dev/3s (technically in GitHub) and ask they only do it in those specific circumstances rather than label people behaving as /dev/3s as /dev/4s solely to overcome a technical issue.
We have generally referred people to the GitHub Code of Conduct page when granting them access to repos. That practice should continue. I don’t think we have a “so now you can push” page. Some of that might be covered in the code of conduct page, but it wouldn’t hurt to have pages specifically designed for people entering a new stage of development.
This is very helpful framing. @vinay, @bharatak, @rnjn, @vinkesh (cc @petmongrels), you should think about and let us know whether you would see yourselves as /dev/3 or /dev/4 on this spectrum. The answer doesn’t have to be the same for everyone. Once we know what role you’ll be aspiring to play, we’ll know the best way to get you the privileges you need.
Point 2 from Burke’s reply isn’t clear to me, how do you make sure that devs with temporary-core access only push changes or merge pull requests relevant to the specific task? Is there way to achieve this in github or is it manual?
Interesting post Darius, thanks for sharing it, in Karl’s post one of his arguments and assumptions is that the team regularly looks at and reviews all commits in the project which personally i rarely do, not sure about the other devs, instead we review pull request before they get merged but i do agree with the honor system.