The TZIP Process is completely broken and dead

Tezos Agora is mostly quiet. The TZIP process is broken and dead. Little dev chat happens in the open. We seem to have alienated all VCs and possible partners. Many dev teams appear to have given up and gone elsewhere.

Not all of these problems are new, but maybe amplified in the current state. Agora has always been quiet. Many personally have never posted anything there as most posts get 0 to 1 reply so what is the point? Some posts get more but by far Agora has never been as active AS IT SHOULD BE. TZIP process has been ground to a halt since TQ split up. TQ used to steward the TZIP process, and now we’re left to do it ourselves. Nobody has really stepped up, teams are more and more isolated and not working together as much. There are at least 59 people who have the capability to approve TZIP merge requests. Getting an MR through only takes 2 approvals. There’s no reason the process shouldn’t be moving forward, but it’s just not because we lack a TZIP steward. I don’t think we need a “steward” like TQ used to do, but we do need an active MR team that actively reviews MRs so the process is always at least moving forward. If you submit a TZIP MR today, it goes to /dev/null. Even an submitted update to TZIP-021 which was a change approved by actors across the ecosystem, and still it’s a mission impossible to get the two approvals to merge it in.

59 people who have the capability to approve TZIP merge requests and struggling to get two is a big fail of the current state!

If we’re going to push standards forward we need an active merge request team who can review and comment on or take action on merge requests at least weekly. There are at least 50 other people who have the power. Who else volunteers as tribute? IMHO the “merge request team” should be at least 5 people (merge requests require 2 approvals). Anyone with at least Developer role in the project or any user or group with Approver access.
Most the current list of people who can approve appear to be core protocol devs. It’s a bit weird because TZIPs can be either core protocol proposals or standards proposals and those are in general 2 very different groups of people.

The TZIP repo is public and Gitlab is more than capable of handling a communication thread on a proposal. I don’t personally understand why anything more than the system Gitlab provides needs to exist. It works for thousands of open-source projects and requiring use of this other thing just creates friction. The process needs to be a simple as possible to get people to start using it again. Anything else, people will just say screw it.
IMHO for standards we form a small team capable of getting it done and just start doing it. If others take notice and want to join in, awesome. But we have to start somewhere and set the path for others to follow. Waiting for the environment to be right and all the things to line up is not going to work.

9 Likes

No response or even a discussion to the points here made although I intentionally choose this controversial clickbait title says more than a 1000 words and proves the points beeing made here. I see that this post got four likes so people agree with that. Maybe 4 is not much but for Tezos Agora thats a ton tbh

1 Like

I am not on Tezos ecosystem for a long time, but I have the impression that this forum is public to core team discussion whereas the core team is using a lot Slack internally for core team to core team topics. Also, gitlab is another way of doing project management / tracking issues

Thanks for the post. Maybe there is a need to teach more community members how to participate in liquid democracy?

I understand that discussion happens slack but whats the point in Agora when most of the talk stuff happens behind “closed doors” for the public. In order to thrive as a dev community we should encourage to make public discussions happen.

Regarding gitlab, yeah I know but still the TZIP process does not work at all. As there are open TZIP merge requests on gitlab and its not possible to get two approvals or feedback why there will be no approval. While over 50 people have the rights to do so.

Here some examples:
Closed because of no interest…

I agree with the need to have more discussions in the open – but it is inevitable and natural that certain discussions happens internally: you don’t want to have all operational/strategic discussions about a protocol proposal, or the crews implementing a particular project/milestone directly on Gitlab, or even here.

That said, it is also difficult to enforce the discipline of reflecting sufficient information publicly (e.g. reporting on an MR on the discussion you had face to face or over Slack directly with reviewers)

We have discussed time and time again how to improve the flow of information, specially from the core development teams towards the community. I reckon we have been making an effort to have more public facing development documentation available, for instance in Gitlab milestones , and also producing more communication material offering earlier preview to development goals.

That said, I admit we have room for improvement and I am particularly interested in hearing suggestions.

1 Like

No response or even a discussion to the points here made although I intentionally choose this controversial clickbait title says more than a 1000 words and proves the points beeing made here. I see that this post got four likes so people agree with that. Maybe 4 is not much but for Tezos Agora thats a ton tbh

That’s a bit unfair. I reckon one another issues we have a is a multiplication of conversations happening in different spaces, about the same topics and it is hard to be everywhere.

1 Like

Regrettably the issue is that that number does not reflect how many of those folks have the bandwith or the mandate to handle tzips. Which reflects the need for an improved system, with enough motivated folks willing and capable of shepherding tzips – and with the time to do so!

2 Likes

I agree with all your points made. I intentionally chose a bit provocative language(but it does not change the current state though, its a fact) to draw attention to this problem because I think it is significant.

This is not my idea, it was suggested by @codecrafting to form a dedicated active merge request team who can review and comment on or take action on merge requests at least weekly. I think thats a great idea and first step into the right direction. Also @jdsika did have great thoughts on this topic and even suggested a meeting during Tezos Paris on slack in #tezos-standards-discussion channel.

I reckon we have been making an effort to have more public facing development documentation available, for instance in Gitlab milestones , and also producing more communication material offering earlier preview to development goals

The milestones page is great I know it(maybe not enough known to the public) and I love articles on Nomadic Labs website and hope to see more about different aspects/topics. They are great and we need more of it :slight_smile:

Hi all, sorry for the late reply which also reflects the fact that most people are cought up in daily business lacking the time to work on these overarching topics. It is is fact not a problem isolated in the Tezos ecosystem but also in the automotive industry it is EXTREMLY hard to find people participating in groups even if you could just “order” them to :smiley:

To the points made before me:

  1. A MR Team or “Change Control Board”:
  • we successfully use it at the Open Simulation Interface for example
  • The group should consist of experts with regard to the implementation of the specification, users like block explorers and e.g. NFT platforms - this also is a factor to spread the information as they have the responsibility to evaluate the impact of changes on their ecosystem
  • The group itself needs governance anyway… weekly/bi-weekly online meetings, a “head” of the group organizing it, splitting work items for offline, pulling people into the process etc
  1. I agree that GitLab is sufficient as a platform to facilitate the process if we add “teams, google meet” maybe a shared calender to subscribe to whatever etc to the list but also someone who organizes some meetups etc.
  2. In industry these things are in general facilitated through non profit organizations dediated to that where all members pay a small fee to pay for this (OVERKILL for here) BUT keep in mind that there needs to be a compliant framework. I raised some questions here
  3. To make an example for the need for governance: Sadly the CC0 license is not usable :frowning: how could we e.g. establish a way forward to change that if we cannot find 2 people to approve a simle typo edit? damn license topic
  4. Normally the largest entities take responsibiliy for the overhead, in my case BMW spends time/people for steering boards, change control boards, management boards etc… maybe here NL could offer assistance? The small developers must be encouraged to spend time by seeing that their technical input leads to quick and good results.

Maybe someone from NL can offer a spot/date/time for our Paris TZIP onsight meeting? :slight_smile:

3 Likes

Has there been any movement on this topic? I’m curious if there’s a way for me to contribute.

1 Like

We had some very fruitful discussions at the TezDev event! I have collected the inputs (until now in my mind) and will write a summary. At fist I will send those to the people directly that I have talked to in order for them to comment on it - I may have forgot something. If there is consensus and my mental notes were correct I think the possible path forward will be communicated to the broader community for comments.

4 Likes

Hi! Thank you all for flagging this, and for the open discussions at TezDev!

I’m currently gathering various inputs and feedback relating to core development, and I’m happy to help share this relating to the TZIP process.

This topic has come up the various core development teams, and the following action plan may be best:

  1. Moving forwards, TZIPs should focus only on standards, and not on improvements. For instance, standards defining consistent behaviour or interaction of multiple products – like FA2.
  2. Merge or close open MRs in the tzip GitLab repo. We should also deprecate TZIPs that are not relevant, or not defining standards.
  3. Clarify the status of relevant TZIPs, and get them progressing.
  4. Ask everyone to share problem statements and ideas on Agora first, before writing TZIPs.
  5. Gather a small group of editors from projects actively building on Tezos to review TZIPs regularly.
5 Likes

At Nomadic Labs we have been actively discussing this as well, and we share this vision for the TZIP process. We believe the end result will enable quicker communication and foster increased cooperation across the whole Tezos ecosystem.

2 Likes

devs give no exposure on discord. the slack is quite difficult to obtain info about, let alone make a point that is heard. tezos is in present tense just a justification for a TF grant spigot to the usual suspects.

TZIP process being dead is like, the least bad thing you noted here.

The problem is that tezos is just not a great place to be a developer at the moment. The biggest projects are either clearly scrounging for cash or making money in other markets and using tezos as a side project.

1 Like

Its great to see movement now in this process. Great to see @asutosh trying to manage the TZIP process. I guess this thread can be closed soon :slight_smile:

1 Like

Thanks for the encouragement @Britcoin. With the support from the community, we will be able to improve the process slowly but steadily towards ideal.

1 Like