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.

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

Add new maintainers for subsystems #629

Open
sdboyer opened this Issue May 23, 2017 · 6 comments

Comments

Projects
None yet
2 participants
@sdboyer
Copy link
Member

sdboyer commented May 23, 2017

dep is moving quickly - quite quickly! - and I can no longer reasonably keep up with the volume of issues and PRs. Fortunately, we've got some wonderfully dedicated and knowledgeable people who have been taking on more and more work within the project. It's time to start formally handing out responsibility for maintainership of subsystems to experienced contributors who are willing to shoulder the load 😄

We'll organize dep into logically distinct subsystems (as much as possible), and look for maintainers of each of those. (There'll likely also be some shared code that isn't under any individual maintainer's purview) We've actually already done this once - last week, @carolynvs became the maintainer for dep init! 🎉 🎉 🦄

There are a couple prerequisites for doing more of this, though:

  1. We need some written guidelines for maintainers, to keep us all on the same page, and to help newcomers know who they want to be talking to.
  2. As much as possible, we need to divide the code so that maintainership boundaries mirror package boundaries. Carolyn already opened #609, which we can use for that.
  3. And, of course, add a MAINTAINERS file in the root.

If current contributors are interested in doing maintainership work, feel free to indicate as much on this thread - though it's probably better to PM me about it in slack 😄

@sdboyer

This comment has been minimized.

Copy link
Member

sdboyer commented May 31, 2017

Here's a high-level sketch of what I can picture as independent subsystems. This is arranged as a tree because that's how I think of it - it should not be read as implying or necessitating any particular hierarchy or social power structure.

  • dep
    • init
    • ensure
    • status
  • gps
    • solver
    • source manager
      • root deduction
      • source/vcs interaction
      • caching
    • pkgtree
    • versions and constraints

We have almost no clear package boundaries around these areas, which can make the boundaries of maintainer responsibility a bit fuzzy. However, I don't think it's a good idea to split up packages just for administrative purposes; rather, maintainers will need to communicate and get along with each other, working collaboratively on issues that either land in fuzzy areas, or clearly cross lines.

@sdboyer sdboyer self-assigned this Jun 6, 2017

@sdboyer

This comment has been minimized.

Copy link
Member

sdboyer commented Jul 20, 2017

(still looking for people for this 😄 )

@sdboyer

This comment has been minimized.

Copy link
Member

sdboyer commented Jul 20, 2017

yay, we'll be adding @jmank88 !

@sdboyer

This comment has been minimized.

Copy link
Member

sdboyer commented Jan 23, 2018

still looking for more people here to help share the load - and also, a docs maintainer would be amazing 😄 😉 ❤️ 🎉

@JGailor

This comment has been minimized.

Copy link

JGailor commented Jan 25, 2018

Never been a docs maintainer, but I've been writing code for a long time and am interested in giving something back to the community. If you reach out to me with more information, I would like to help.

@sdboyer

This comment has been minimized.

Copy link
Member

sdboyer commented Jan 25, 2018

@JGailor amazing, yay! 🎉 🎉 🎉

what i'd be looking for in a docs maintainer is:

  • Become intimately familiar with the body of documentation we have on the site (i am happy to help with this process, answer questions, etc.)
  • Review PRs as they come through for changes that induce docs changes, and either point the contributor to where the change needs to be, or (if possible/appropriate) make the changes themselves
  • Keep a general eye on the issue queue for questions or misconceptions that seem to come up frequently, and think about how docs can be changed or improved so that people don't have these questions at all

Basically, know what the docs are, when they need to change, and use the context you have to think they can be improved.

Could you DM on the gophers slack so we could talk about it some more?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment