Requesting /dev/4 stage for Bahmni team members

Development Repo Management
1

Hi @burke , @darius ,

Vinay (vinayvenu), Bharat (bharatak), Ranjan (rnjn) and Vivek (petmongrels) are all tech leads on the bahmni team. Would it be possible to grant us all the same github privileges?

We would want to be able to merge PRs for some of the new functionality we will be implementing for 1.12 and maybe some bug fixes as well.

2

@burke @darius forgot to include another person. Could you please include Vinkesh Banka (vinkesh) as well?

Thanks.

-Shruthi

3

@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”?

4

I know Shruthi suggested my name. But please feel free to leave me out from commit rights perspective.

5

@darius i don’t think we have a page that says, here is what you need to know, the dev stages’ page only lists what is expected of them

6

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.

7

To be explicit, the specific driver here is:

  • 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:

  1. 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)
  2. 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
  1. 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).

@burke, your thoughts?

1 Like
8

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.

9

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.

1 Like
10

I am @rnjn, please slot me as /dev/3 for now. Thanks

11

I guess /dev/3 would accurately represent me in the community?

12

Please slot me as /dev/3 too.

13

Thanks Darius and Burke!

I would think that we fit /dev/3 description better than /dev/4. If /dev/3s are granted push access, that would work for us as well.

Thanks.

-Shruthi

14

Hi,

I think I fit in /dev/3 .

Thanks,

15

I see that the answers are consistent. :slightly_smiling:

On github I have added Vinay and Vinkesh as /dev/3s, and invited Ranjan to the organization (and /dev/3 team). Bharat was already there.

And I gave all of you the /dev/3 badge on Talk.

@burke, how do you want to approach giving /dev/3s push access to openmrs-core, while communicating expectations around this?

1 Like
16

How about a new “temporary-core” team in github with write access to openmrs-core using the following convention?

17

Sounds fine to me.

18

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?

19

This would just be by convention +/- the honor system.

Karl Fogel says:

Regarding enforcement of partial commit access: it’s often best not to have the version control system enforce partial commit domains, even if it is capable of doing so.

And you can read more of his thoughts here: Version Control

1 Like
20

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.

1 Like