Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

"Feature maintainers" groups to collaboratively manage site features #6501

Open
jywarren opened this issue Oct 20, 2019 · 25 comments
Open

"Feature maintainers" groups to collaboratively manage site features #6501

jywarren opened this issue Oct 20, 2019 · 25 comments
Labels
brainstorm Issues that need discussion and requirements need to be elucidated discussion support

Comments

@jywarren
Copy link
Member

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-maintainers
  • tags-maintainers (or tags-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-maintainers or search-maintainers or wiki-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
@jywarren
Copy link
Member Author

Each team might have it's own "mission" and "priorities" even - like, for commenting:

  • ensure commenting is error-free
  • improve and refine commenting
  • maintain commenting from a mobile phone
  • maintain comment-by-email
  • simplify and clean commenting code

Commenting might have its own label as well. But the primary responsibility would be to merge comment-related PRs.

@jywarren jywarren mentioned this issue Oct 20, 2019
Merged
@jywarren
Copy link
Member Author

So that we better understand how the system works, I set up @publiclab/comment-maintainers and added @cesswairimu and we will try it out to understand the limitations and features the CODEOWNERS system has (PR at #6502)

@jywarren jywarren mentioned this issue Oct 20, 2019
Closed
5 tasks
@susanreenesaa
Copy link
Contributor

susanreenesaa commented Oct 20, 2019 •
edited
Loading

I think that this is a great idea. because we will be assured that every merged PR has no effect on the project's code. I am basing this on the fact that I have just join open-source software (publiclab). but I realized that when I assign my self an issue (first-timer
-only), then I also have the right to merge PR after its revied( though I am not sure if also before being reviewed I can merge it). However, this could be very risky for the project's code.
#my view

@nstjean
Copy link
Contributor

nstjean commented Oct 21, 2019

Oh I really like this idea! I think organizing by function rather than folder is a better approach, because like you said it allows the group to really be familiar with the full stack of that section and best understand how it all works together. It's easier for someone to be an "expert" on a small section rather than waiting for them to become familiar with the entire codebase.

@sashadev-sky
Copy link
Member

@jywarren this is genius / an important experiment for OS

@sashadev-sky sashadev-sky self-assigned this Nov 21, 2019
@SidharthBansal
Copy link
Member

This is really nice :-)

@jywarren
Copy link
Member Author

jywarren commented Nov 22, 2019 via email

@SidharthBansal
Copy link
Member

SidharthBansal commented Nov 28, 2019 via email

@jywarren
Copy link
Member Author

jywarren commented Dec 2, 2019

OK, i am thinking we can create a few "pilot" areas:

  1. Comment maintainers (the whole comments system)
  2. Editor maintainers
  3. Database maintainers
  4. Navbar maintainers
  5. Profile maintainers
  6. Login maintainers

Some are large and some small. But people who want to just get started could join one with a narrow set of responsibilities -- like database or navbar -- which have few moving parts and mainly just are there to ensure that those areas are stable. Others may get more involved in a complex integrated system like comments or editor.

What do you all think? Would anyone here sign up for one of these and want to get merge rights to that segment of code, if we wrote out a more detailed set of responsibilities and roles for it?

@SidharthBansal
Copy link
Member

From my experience with the GCI going on,

  1. The number of reviewers in each repository is very less. (In total Plots2 have 6 mentors for GCI.)
  2. A number of active reviewers vary a lot due to a busy reviewer's schedule. (In total 3 mentors are active now for plots2 (excluding me and Jeff) )
    So, this approach is a little tough to be real as it is fragmenting things. I am a little afraid that most reviewers will end up in 4/6 maintainer categories listed above.

I am willing to test the above functionality. Unfortunately, I cannot test the above segments of code as I have full repo rights. @IshaGupta18 @ananyaarun @sashadev-sky anyone of you guys want to check this?

@jywarren
Copy link
Member Author

jywarren commented Dec 3, 2019 via email

@SidharthBansal
Copy link
Member

SidharthBansal commented Dec 4, 2019 via email

@jywarren
Copy link
Member Author

jywarren commented Jan 6, 2020

Hi @sagarpreet-chadha @sashadev-sky would you like to sign up for some feature maintainers "zones" and get merge rights for them?

@sashadev-sky
Copy link
Member

@jywarren sure! I will take these 4:
2. Editor maintainers
3. Database maintainers
4. Navbar maintainers
5. Profile maintainers

Does that work?

@jywarren
Copy link
Member Author

jywarren commented Jan 13, 2020 via email

@sashadev-sky
Copy link
Member

@jywarren sounds good! Lmk if you need help with that

jywarren added a commit that referenced this issue Jan 16, 2020
@jywarren
Create MAINTAINERS.md for feature maintainers
40f28a2 
 re #6501
@jywarren jywarren mentioned this issue Jan 16, 2020
Merged
@jywarren
Copy link
Member Author

Yes, i'd love help! I just started a README for the system in #7271. I want to expand the CODEOWNERS file in that PR to launch the pilot! We need to think of what paths to include in the CODEOWNERS file, and add them to that PR.

@jywarren
Copy link
Member Author

cc @emilyashley !

@jywarren
Copy link
Member Author

OK, i just created:

@publiclab/comment-maintainers
@publiclab/database-maintainers
@publiclab/editor-maintainers
@publiclab/navbar-maintainers
@publiclab/profile-maintainers
@publiclab/login-maintainers

@jywarren
Copy link
Member Author

If this works, maybe:

notification-maintainers
node-maintainers
admin-maintainers (for the admin and spam moderation systems)

@SidharthBansal
Copy link
Member

SidharthBansal commented Jan 17, 2020 via email

@jywarren jywarren mentioned this issue Jan 21, 2020
Merged
jywarren added a commit that referenced this issue Jan 28, 2020
@jywarren
Create MAINTAINERS.md for feature maintainers (#7271)
d0b6db8 
* Create MAINTAINERS.md for feature maintainers

 re #6501

* Update MAINTAINERS.md

* Update CODEOWNERS

* Update README.md
vinitshahdeo pushed a commit to vinitshahdeo/plots2 that referenced this issue Feb 1, 2020
@jywarren
Create MAINTAINERS.md for feature maintainers (publiclab#7271)
4a601fa 
* Create MAINTAINERS.md for feature maintainers

 re publiclab#6501

* Update MAINTAINERS.md

* Update CODEOWNERS

* Update README.md
NitinBhasneria pushed a commit to NitinBhasneria/plots2 that referenced this issue Feb 5, 2020
@jywarren
Create MAINTAINERS.md for feature maintainers (publiclab#7271)
b127292 
* Create MAINTAINERS.md for feature maintainers

 re publiclab#6501

* Update MAINTAINERS.md

* Update CODEOWNERS

* Update README.md
@rishabhshuklax rishabhshuklax mentioned this issue Feb 19, 2020
Open
5 tasks
@theOpetunde
Copy link
Contributor

Hi, I'd love to join the support team. I am a 2020 Outreachy aspirant. Thank you

@jywarren jywarren mentioned this issue May 5, 2020
Closed
@stale stale bot added the stale label Oct 7, 2020
@ebarry
Copy link
Member

ebarry commented Oct 7, 2020

Ok this is an active idea, and we have @jywarren and @sashadev-sky working on defining Feature Suites this fall and using them for prioritization and project scoping so we need to keep this open and further promote these maintainer groups.

@stale stale bot removed the stale label Oct 7, 2020
@ebarry
Copy link
Member

ebarry commented Oct 7, 2020

I'm interested in the progression of someone completing a Summer of Code or Outreachy project through which they've developed expertise and institutional knowledge of particular features, and how they would join a team. Do we need to add a moment to review, check in with people, and add some people who wish to stay involved to teams at the end of each summer? Other ideas?

@ebarry ebarry added the brainstorm Issues that need discussion and requirements need to be elucidated label Oct 7, 2020
@jywarren
Copy link
Member Author

jywarren commented Oct 8, 2020

This is not stale, there seems to have been an error with the GitHub API and we can no longer delete stalebot messages, so please disregard! Thanks!

@publiclab publiclab deleted a comment from stale bot Oct 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
brainstorm Issues that need discussion and requirements need to be elucidated discussion support
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@jywarren @ebarry @SidharthBansal @sashadev-sky @susanreenesaa @nstjean @theOpetunde