Plots2: "Feature maintainers" groups to collaboratively manage site features

[jywarren]

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]

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]

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 https://github.com/publiclab/plots2/pull/6502/)

[susanreenesaa]

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]

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]

@jywarren this is genius / an important experiment for OS

[SidharthBansal]

This is really nice :-)

[jywarren]

Ok, shall we start with a pilot "area"? Did commenting make sense as a good
first one? Thanks, all!

On Thu, Nov 21, 2019 at 2:39 AM Sidharth Bansal [e-mail]
wrote:

This is really nice :-)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/publiclab/plots2/issues/6501?email_source=notifications&email_token=AAAF6J5A3B4NRUV6U67K6MLQUY3HJA5CNFSM4JCT2QTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEZIP2I#issuecomment-556959721,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAF6JZXTY5KY32WVUXPMWTQUY3HJANCNFSM4JCT2QTA
.

[SidharthBansal]

Cool!

On Fri, Nov 22, 2019 at 11:54 PM Jeffrey Warren [e-mail]
wrote:

Ok, shall we start with a pilot "area"? Did commenting make sense as a good
first one? Thanks, all!

On Thu, Nov 21, 2019 at 2:39 AM Sidharth Bansal [e-mail]
wrote:

This is really nice :-)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<
https://github.com/publiclab/plots2/issues/6501?email_source=notifications&email_token=AAAF6J5A3B4NRUV6U67K6MLQUY3HJA5CNFSM4JCT2QTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEZIP2I#issuecomment-556959721
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AAAF6JZXTY5KY32WVUXPMWTQUY3HJANCNFSM4JCT2QTA

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/publiclab/plots2/issues/6501?email_source=notifications&email_token=AFAAEQ64Z2HOMZZG6MP5L63QVAPV7A5CNFSM4JCT2QTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE6OPKY#issuecomment-557639595,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFAAEQ7XNORPQXHLAXZF2Y3QVAPV7ANCNFSM4JCT2QTA
.

[jywarren]

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]

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]

I guess i had wondered if people would be interested in "turning off"
notifications to everything but the area they're involved in as a feature
maintainer, and so throttling a bit their level of involvement, but
deepening it while narrowing it. But it's a fair point to be worried about!

On Tue, Dec 3, 2019 at 2:14 AM Sidharth Bansal [e-mail]
wrote:

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
https://github.com/IshaGupta18 @ananyaarun
https://github.com/ananyaarun @sashadev-sky
https://github.com/sashadev-sky anyone of you guys want to check this?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/publiclab/plots2/issues/6501?email_source=notifications&email_token=AAAF6J2J4UBGXWJIBIF6XZTQWYBM5A5CNFSM4JCT2QTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFYLEEA#issuecomment-561033744,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAF6J6EDQMS6B5MUXWBPJLQWYBM5ANCNFSM4JCT2QTA
.

[SidharthBansal]

That's a good idea!

On Wed, Dec 4, 2019 at 2:28 AM Jeffrey Warren [e-mail]
wrote:

I guess i had wondered if people would be interested in "turning off"
notifications to everything but the area they're involved in as a feature
maintainer, and so throttling a bit their level of involvement, but
deepening it while narrowing it. But it's a fair point to be worried about!

On Tue, Dec 3, 2019 at 2:14 AM Sidharth Bansal [e-mail]
wrote:

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
https://github.com/IshaGupta18 @ananyaarun
https://github.com/ananyaarun @sashadev-sky
https://github.com/sashadev-sky anyone of you guys want to check this?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<
https://github.com/publiclab/plots2/issues/6501?email_source=notifications&email_token=AAAF6J2J4UBGXWJIBIF6XZTQWYBM5A5CNFSM4JCT2QTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFYLEEA#issuecomment-561033744
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AAAF6J6EDQMS6B5MUXWBPJLQWYBM5ANCNFSM4JCT2QTA

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/publiclab/plots2/issues/6501?email_source=notifications&email_token=AFAAEQ4TDX5Y7QR4K57YB73QW3B7TA5CNFSM4JCT2QTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF2ZKVQ#issuecomment-561354070,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFAAEQ7PFDQFNGXFF7J44Z3QW3B7TANCNFSM4JCT2QTA
.

[jywarren]

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

[sashadev-sky]

@jywarren sure! I will take these 4:

1. Editor maintainers
2. Database maintainers
3. Navbar maintainers
4. Profile maintainers

Does that work?

[jywarren]

Yes, that's great! We have to generate a list of paths that'll be covered,
and then we'll add you for those.

On Mon, Jan 13, 2020 at 12:21 AM Sasha Boginsky [e-mail]
wrote:

@jywarren https://github.com/jywarren sure! I will take these 4:

1. Editor maintainers
2. Database maintainers
3. Navbar maintainers
4. Profile maintainers

Does that work?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/publiclab/plots2/issues/6501?email_source=notifications&email_token=AAAF6J7IWXANJQ7TRYOW2O3Q5P26BA5CNFSM4JCT2QTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIXRULQ#issuecomment-573512238,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAF6JYR3JVIQAW3INDAMBLQ5P26BANCNFSM4JCT2QTA
.

[sashadev-sky]

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

[jywarren]

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]

cc @emilyashley !

[jywarren]

OK, i just created:

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

[jywarren]

If this works, maybe:

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

[SidharthBansal]

Great

On Fri, 17 Jan 2020, 5:35 am Jeffrey Warren, [e-mail]
wrote:

If this works, maybe:

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

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/publiclab/plots2/issues/6501?email_source=notifications&email_token=AFAAEQYZJI43OGIU2XM63E3Q6DY3ZA5CNFSM4JCT2QTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJF7VJA#issuecomment-575404708,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFAAEQ2QOYWYBII5LSZETFLQ6DY3ZANCNFSM4JCT2QTA
.

[theOpetunde]

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

[ebarry]

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.

[ebarry]

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?

[jywarren]

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!