Add new maintainers for subsystems

[sdboyer]

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 Extract command implementions into sub-packages #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]

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]

(still looking for people for this 😄 )

[sdboyer]

yay, we'll be adding @jmank88 !

[sdboyer]

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

[JGailor]

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]

@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?