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

Project Updates
1

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.
9 Likes
2

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

2 Likes
3

Hello @asutosh is the tzip merge team active? There are 12 MRs open ans some since months with no activity: Merge requests · Tezos / tzip · GitLab
Also the typo MR should be a quick one to finish imo.

4

Unfortunately the merge team is not very active, I’ll gather interest from people and will try to re-active it.

2 Likes
5

You meant its not active at all…? Come on man its just frustrating

6

Hello, now the TechRel team is taking care of the process, we will tackle one by one each MRs, please tell me how you would like to help/participate.

3 Likes
7

As Beata said above, it’s active again now. That’s not a temporary thing: it’s a duty of the recently created Technical User Relations team (aka TechRel).

2 Likes