Description
We've been working towards a more shared model of maintainer responsibilities, and I've been discussing this on and off with folks like @cesswairimu @IshaGupta18 @gauravano @SidharthBansal and @sashadev-sky, some of us especially in the last few days.
Here at the Google Summer of Code mentor summit, I learned of a cool feature in GitHub called Code Owners, which can automatically generate a review request for a user (or group!) based on if a pull request has changed files in a particular folder. (https://help.github.com/en/articles/about-code-owners)
This is really cool and it brings up the possibility of having groups that have merge rights but are responsible for only specific areas of the codebase -- this will make it easier to know enough about a system to give a good final check (after reviews) and be sure it doesn't break anything, without having to know the entire codebase. This can then reduce our merge-rights bottleneck, but not bring a lot of risk of breaking code.
I love this idea because we can start small, and @cesswairimu felt that the best way to develop groups was not around specific folders of code, like /app/models/, but around code features.
So, for example, we might have a @publiclab/comments-maintainers group, who have merge rights and responsibilities for the comments system -- including:
/app/models/comment.rb
/app/controllers/comment_controller.rb
/app/views/comments/
/app/views/notes/_comment.html.erb
/app/views/notes/_comments.html.erb
/test/unit/comment_test.rb
/test/unit/comment_mailer_test.rb
/test/functional/comment_controller_test.rb
/test/functional/comment_mailer_test.rb
and maybe a few more. This is harder to write in the CODEOWNERS file, but is nice because it contains all code that makes up the full-stack commenting system. It kind of encourages a holistic responsibility for not just the templates, or models, but the tests, the UI, everything related to comments.
What do people think about this? We could do similar feature maintainer groups for other code areas. And we'd still require reviews - this would just be the final responsibility to merge a PR, and be responsible in case anything breaks.
Features I could think of to develop a team around (if our first pilot/prototype team works well) include:
editor-maintainerstags-maintainers(ortags-maintainers/and/tag-page-maintainers?)login-maintainers- for the signup and login systems, a really critical system, so it might have special rules?- maybe narrower groups like
dashboard-maintainersorsearch-maintainersorwiki-maintainers? - we could specialize even more, because actually, specializing can make it /easier/ to know enough to feel comfortable taking on this responsibility, if it's over only a few specific systems, maybe?
I'd love to hear input on this idea. We could try an initial attempt, and refine/change the idea once we see how it works, and gradually build out more teams of this type. What do you think?
@publiclab/reviewers @publiclab/support @publiclab/mentors @publiclab/soc