Updating our DEP process / DEP 1

I absolutely agree with Sarah, Lily and Ken. Other examples of feature request threads are:

Relatedly, this Discord thread on #contributor-discussion (specifically about consensus), felt somehow discouraging, as if things would intentionally be hand-wavy and slow:

[…] this thread started because people here thought the consensus approach as it plays out currently is often:

  • Prone to stalling
  • Drawn out over months or years for no other reason than the process being poor
  • Very arbitrary

[…] those three points are by design.

As a fellow, when I have to close a feature-request-as-a-ticket as wontfix, redirecting the reporter to the forum (as I understand this is the procedure), I feel uneasy because the request seems doomed from the start due to the inherent ambiguity and lack of clarity in the “getting consensus” process.

I would love if we could establish clear steps, rules, and procedures for proposing, reviewing, and deciding on features. Even better if this happen in a “reasonable” time frame.

Concretely, I think we need:

  1. A way to “list” all the feature request proposals needing a resolution. This could be its own category in the forum, or perhaps a new “Triage Stage” in a ticket (shall bringing back “design decision needed” be reconsidered?)
  2. A non ambiguous way to define when consensus was reached (for both “yes, let’s do it” and for “no, let’s not pursue that at this time”)
  3. An explicit threshold (time based? amount of participants based?) to conclude if the proposal is accepted or not
6 Likes