Developer Stages and Modules

Development
1

I’m looking at Developer Stages and wondering about the different module related expectations/privileges:

  • /dev/2
    • Expectations: Can create a module
    • Privileges: Publish a module and resources to Maven repo
  • /dev/3
    • Privileges: Push to module(s)

Why is a /dev/2 allowed to publish a module to Maven repo if one must be a /dev/3 in order to push to a module source code repo? Or does “push to modules(s)” mean something else? Is uploading to modules.opernmrs.org included in “Publish a module and resources to Maven repo”?

I was trying to check if its is ok to grant admin privilege for a /dev/2 to a specific module at modules.openmrs.org and thought I’d bring this up.

1 Like
2

The intent is:

  • Contributing (/dev/2) – a developer actively contributing their work to the community. This can be in the form of individual commits, fully functional modules, or other contributions. A /dev/2 is not expected to be thinking beyond their own project(s).

  • Cooperating (/dev/3) – a developer who goes beyond contributing to attempt to coordinate their efforts with others. A /dev/3 is expected to be thinking beyond their own project(s).

So,

  • A /dev/2 can contribute their modules to the community by posting them within the module repository. They can host their code in their own GitHub repo, outside of GitHub, or may choose not to share their source code. To contribute source code to shared modules, a /dev/2 would need to submit a pull request.

  • A /dev/3 can contribute source code directly to the repository for shared modules, since they are expected to think beyond their own needs (i.e., at least how their changes may impact others).

Does that help?

-Burke :burke:

3

We should probably be careful in how we communicate this. :slight_smile:

Feel free to disagree, but I would imagine we don’t want to necessarily encourage people to be committing lots of code without code review via pull requests. However, I do think that having /dev/3 be a criteria to merge code is probably the right way to think about it.

What do others think?

3 Likes
4

I think you’re right, maybe it should be something like:

A /dev/3 can contribute source code directly merge a pull request (after the proper code review process has been completed) to the repository for shared modules…

5

Yeah, let’s not have what happened during GCI happen again. I felt really, really bad about doing that one bad merge.

6

Correct. Sorry for the miscommunication. My goal was to say that /dev/3 would have push access (e.g., to merge pull requests and, when appropriate push changes to the repo), not that they would bypass code review.

3 Likes