TZIP Process Improvement: Process Managers Committee(new name "The TZIP Merge Team")

Hi All,
In an effort to improve the TZIP process and provide better support to the community, we in the TZIP Process working group discuss the following process improvement. Please take a look at the proposal and share your feedback.

Process Managers Committee (new name “The TZIP Merge Team”)

Background

The current TZIP process requires authors to submit MR when the proposal moves to different statuses (‘Draft’, ‘Submitted’, ‘Final’). This MR needs to be approved by someone (currently by 2 people). However, who will approve this MR and the criteria that should be followed aren’t well defined. This creates the following challenges:

  • The MR may not be approved or rejected for a very long period as a result the TZIP gets stuck.
  • The author doesn’t understand the criteria for moving from one status to another and as a result, may not take the necessary steps.

This proposal aims to improve this.

Proposal

  • Create a committee of volunteers who are responsible for acting on MRs. We will call this committee the Process Managers Committee.
  • One person in the committee is identified as an organiser who looks at incoming MRs and involves others from the committee. This responsibility should rotate.
  • For each MR this committee follows some defined guidelines(defined later), however, these are just guidelines and the committee can make an exception with justification for specific cases
  • This committee is initially selected by the TZIP working group and later it becomes self-organising.

Guidelines for approving MR

Process Managers should follow the following guidelines to make an assessment if they can approve MR:

→ Draft

  • The proposal has been shared in different forums, especially Agora. Verify the Agora post.
  • Enough time has lapsed for feedback to flow in organically (~ 2 weeks).
  • Make an assessment if feedback has been addressed (incorporated/ resolved).
  • As this is an early draft, and the starting point for the proposal, we don’t need to be very strict on the approval criteria.

Draft → Submitted

  • The current status is Draft
  • Any additional feedback has been addressed.
  • A proof of concept has been created and shared.

Submitted→ Final

  • The current status is Submitted
  • There is no open feedback.
  • More than one production implementation is available

Trigger to move to the next Status

Status Description Trigger to move to the next Status
Draft It is an early version of the proposal hence expect rapid iterations of the proposal initially. A draft becomes more polished by addressing feedback. A proof of concept should also be planned with the proposal, wherever applicable. A proof of concept is created, wherever applicable.
Submitted The proposal is more or less unchanging at this time. Though it is not yet production tested, it is ready to be used in a production implementation. >1 production implementations are available.
Final More than one production implementation is available, reflecting wider adoption.
8 Likes

One primary feedback regarding this was on the name. We will be calling the group of approvers “the tzip merge team”.

1 Like