Status

RESOLVED 

Blocking
OutcomeAPPROVED
Minutes Link2020 05 21 TSC Minutes

Overview of Proposal

A few projects have documented the way they manage their maintainers but it would be desirable to increase consistency in how this is done across all the projects. This proposal is about defining a common Maintainers management policy that could then be adopted by the projects.

The following list points to the known existing policies (please add any other that is not listed here):

Formal Proposal(s)

TBD

Action Items

  • Type your task here, using "@" to assign to a user and "//" to select a due date

Reviewed By


4 Comments

  1. Gari Singh

    I'm not sure that every project needs to have the exact same policy, but agree that it would be good to have a standard / common list of things each project can adopt if it likes.  For example, "removal for inactivity" is a good practice, but some projects might say 60 days and others might say 90 days based on each project's own contribution pattern(s).

  2. Danno Ferrin

    Because each project had their own policy i agree it's going to be hard to get every project to adopt the same policy.  But I think we need consistency on what the policy covers.   For example, a "removal for inactivity" clause should be in each policy, even if the policy is "no removal for inactivity".  Perhaps a minimum of:

    • How to add maintainers (who can propose, what preconditions should be met for proposal, length of voting window, strict majority vs majority of voting, are vetos a thing)
    • Removal for inactivity
    • Mechanism for removal for other reasons (Code of conduct, for example)

    and the policy could suggest other things to consider when making or updating a policy, such as

    • "Scope" of maintainership (whole project, repo, part of a repo) and how scope gets adjusted
    • If there are different classes of maintainers, how they are selected
    • If there is a conflict between maintainers (architecture, coding, etc) how that conflict gets resolved.
    • If there are duties maintainers need to perform, such as regular maintainers calls, and quarterly reports, and determining who is responsible for their execution. (If everyone is responsible, no one is).


  3. Hart Montgomery

    There are some cases where you may want an even more fine-grained maintainer policy.  For instance, Ursa breaks maintainers into categories.  Someone who "knows the math" of crypto is required to review changes that touch "the math."

    That being said, it would be nice to have a common maintainer clause that projects could adopt and add to as they see fit (as Gari suggests).

  4. Tracy Kuhrt

    Please see https://github.com/hyperledger/tsc/pull/1