I wanted to leave a little time for other perspectives in here, but it’s been a week, so I’ll address the responses from @Valdorff and @langers
Yes, it might be. I do think that regardless of what process we adopt, we are going to see a reduction in response time. In an ideal world, throughput can be improved because there are more extensible structures in place, even though the end-to-end of an instance of the process takes longer.
We may also have a different idea of what full technical specs are in this context. I would consider the contents of RPIP-28 and RPIP-30 as sufficient to meet this, as an example. It just needs a clear unambiguous specification of what changes in logic should occur. Reference implementations I would consider optional.
Yes, agreed. I’d not considered the non-smart contract changes (bad assumptions on my part.) That said, I don’t think they are terribly incompatible with the processes above? You have releases 2-4 times per year, those releases can contain smart contract changes, settings changes, smartnode changes, etc.
Urgent changes can bypass this process, and planned changes can be defined and setup to come into affect between releases if necessary for the phasing in of changes.
Non-urgent minor changes could also be implemented between releases. Or you could have a schedule of minor off-chain releases interleaved with the major on-chain releases.
Will address this at the end of the post.
@langers, in general we seem to be thinking along the same lines? Dividing the processes into three seems to be a common thread. That said, some comments:
This is definitely one of the main drawbacks to this atomic approach. Depending on the changes, it isn’t always possible to keep them nice and siloed from the rest. I think the main way to avoid this is to only start serious work on feature implementation (as opposed to specification) after the release contents have been decided and communicated to the DAO.
Will cover this last, as I believe its a major point, and both you and Val disagree with me.
Disagree strongly here that justifications are present in the feature RPIPs and so don’t need to be repeated in the release RPIP. This is a misunderstanding of what justifications are for in these contexts.
Feature RPIPs justify the need for a given feature in isolation, why its good, why its needed etc. “Why should we do this?”
Release RPIPs justify why this feature is needed now in this release and why its needed more urgently than all the other possible features. “Why should we prioritize this over the other options?”
More specifically, the justification-for-inclusion gives the release team the chance to disagree with the priorities expressed by the community in a way which better preserves trust and transparency. It also gives the pDAO a chance to ask questions, and to point out potential flaws in the reasoning the release team is using to justify contents. The end goal being that issues are caught before the release team spends too much time on anything that isn’t going to work.
Yes, I think you’re right and that is preferable. Though I would recommend that you go a little more concrete than t-shirt sizing. IE: A ‘large’ release from this team can accommodate approximately X moderately sized features, Y small ones, etc.
Disagree with this strongly as well. I see this come up fairly frequently (from both company and DAO), and its understandable, but it is going to become a problem at some point if you all keep doing it. It is dangerous to make assumptions about DAO priorities solely from DAO discussions.
The reason we have votes is so that DAO opinion can be measured in a quantifiable way. It is much more arbitrary to observe a subset of participants in discussion and assume that it is the majority opinion. It usually is, but the times where it isn’t will really screw you over.
Discussions and forum polls are a starting point, and a useful gate to prevent work taking place on proposals that are clearly not favoured, however, these are not always an accurate signal. The people actively engaged with the DAO are only a a subset of total voters and so your signal is biased to what the most active participants want.
There is a debate to be had over whether only the active participants votes should count, but this is not the model you are currently using to make decisions. You should try to get the most accurate signal of pDAO priority you can, and this can only come from pDAO voting in some form. Priority scoring of possible release content is a lightweight way of doing this.
On the subject of release ratification
So for clarity my position is that release content RPIPs should not require direct ratification by the pDAO. They may have indictive votes organized by the release team if desired, but this should not be made a requirement. Obviously protocol upgrades (once they get to that point) should require a pDAO vote. Here’s why, but it’ll be a little long-winded.
This comes back to the authority part of power and authorities. Who has the authority to do what in this process?
Propose Items - RPIPs are permissionless, anyone can propose one. So the authority is wide.
Approve Items - RPIPs are ratified by the pDAO, so the pDAO holds the authority here.
Propose Contents - In theory any release team could propose an upcoming release including a certain set of items. So the authority here is again wide.
Approve Content - The complicated one, see below.
Propose on-chain changes - In theory anyone can propose on-chain changes to the protocol. So wide authority.
Ratify on-chain changes - pDAO holds authority (I think? though power is with oDAO currently.)
The authority to approve release content
This is complex because there are two competing priorities here:
Release Team Self-Determination
A release team has the ability to work on (or not) any part of the protocol that they want. The DAO doesn’t have to adopt the work, but anyone can do it. It’s an open system. This point becomes arguable if the release team is fully funded by the DAO, but as a general rule, I believe this is always beneficial. You get better output from people that want to be doing the work they are doing.
Much of the time, a release team should be doing what the pDAO wants, because ultimately the DAO controls what changes are ratified in the protocol. No one wants to do pointless work that will never be adopted. However, DAO’s are not capable of the same level of efficient coordination and long-term planning that a more centralized entity or individual is capable of. For this reason, it’s really important that a given release team be able to ignore the DAO if they believe its for the best.
DAO control of the protocol
The flipside and counterbalance to this self-determination is the power of the DAO to control which changes are adopted by the protocol. Work spent by release teams that is not accepted by the pDAO at point of completion is wasted, or at least delayed as it is restructured.
So ultimately:
- The release team has a solid understanding of what the DAO wants and why, due to priority scoring and justifications attached to specification RPIPs.
- The release team can ‘gamble’ on doing something other than what the pDAO most wants at a given time, however, this is a risk, and so is only worth doing if there is commensurate benefit.
- The DAO understands why the release team has made a gamble (if they’ve done so), because the justification is a part of the (informational) release RPIP.
- The DAO can express disagreement and censure of this decision quantifiably by refusing to adopt the proposed changes at the point of adoption.
Why is this better than just voting on the contents early?
- It gives more time to consider the results of any gamble. At the point the work is done, the need that was initially unclear may now be evident.
- Ratification of the release RPIP ties the release team to those contents in a way that requires another vote to modify (at least for non-trivial changes). No ratification gives the release team the freedom to modify contents (with clear justifications) during the implementation period if they believe its for the best.
- It provides more opportunity for trust to develop between the DAO and its release teams. Opportunities exist in this structure for both sides to take chances and live up to expectations in a way that is not possible if one side dictates to the other.
- It prevents harmful misunderstandings of the DAO-team relationship. Say under a release-contents-require-ratification system a release is late, but the team also have produced something unrelated. Did the team do something wrong? They have failed to deliver something ratified by the DAO, and instead delivered something unrelated using the same resources. If the team is seen as working for the DAO, this will be seen as wrong, and will invite criticism. If the team is seen as a partner to the DAO there is much less justification for criticism.