How should we prioritize what to work on?

[effectfully]

This issue is for discussing how the Plutus team should prioritize work. Everybody from @IntersectMBO/plutus-core is encouraged to contribute, but we are interested in opinions of external people as well and welcome everybody to express their opinions.

[effectfully]

My own opinion is that we should prioritize the following:

(0) ledger needs
(1) safety
(2) adoption
(3) iteration speed

For everything else we should try to push it to external teams as much as possible, whether through Catalyst or from contractors or by soliciting community contributions or in any other way.

A good example of (0) is work (1, 2, 3, 4) that had to be done to unblock Conway.

Safety and adoption are inherently at odds with each other: the more features a system has, the larger the attack surface is, and the more funds it manages, the bigger the appeal to hack it is. So (1) and (2) should together read as "we intend to expand as much as possible without compromising the safety of the system".

A good example of (1) and (2) together is the work done by Koz and Kenneth on the bitwise builtins. We need those for adoption and a lot of time has to be spent on them to ensure that the overall risk of losing user funds doesn't increase significantly.

Similarly, triage is crucial for both (1) and (2). Triage is how we make sure that we actually look into the reported issues, which is not only important safety-wise, but is also a demonstration to our users that we're there to help and we care about users' needs.

Safety should be heavily prioritized particularly when it comes to core functionality, for example testing runtime behavior of builtins or sorting out a "runtime type system" for UPLC.

Adoption includes any work that affects users in a positive way, for example performance improvements leading to increased expressiveness of the system and decreased execution costs fall under (2) as well. Documentation is obviously important for adoption too.

(3) is about addressing tech debt and making sure the development process is smooth and sustainable. It's supposed to be easier to contribute to a project the longer it evolves, not harder, which is unfortunately very far from being an industry standard. As developing Plutus becomes easier, we can spend less and less effort for getting tasks related to (0), (1) and (2) done and our overall throughput increases without compromising quality. In my experience frequently removing friction from a software develop process pay off big time in the long run.

Overall, I'd rather see us working on safety, crypto primitives etc than something like blueprints. Sure blueprints are nice to have, but given that we're spread pretty thin I believe that it makes sense to focus on the core aspects of what we do instead of adding bells and whistles.

Anyways, these are just my thoughts and I may be missing things.

[zliu41]

I just want to reiterate a point I made recently: priorities are people-dependent. Letting people sometimes do work that, while less important according to some pre-established criteria, but they find motivating and energizing, can be a very good thing in the long run. Of course, it is to be done in moderation. So while we can publish a list of priorities, there are more nuances to it, and people should not feel that they are working on the wrong thing if what they are doing at any given moment is not one of the top categories.

[effectfully]

@zliu41 I one hundred percent agree with all of that. This issue is not to impose anything, it's to provide clarity as to what constitutes "most important work". None of that implies that we should always be automatically assigned the task that is deemed most important at any given moment with no ability to choose.

[zliu41]

Right, it's more clarification than disagreement, since otherwise people may (either consciously or subconsciously) interpret it as a strict order.

[kevinhammond]

Performance comes into this somewhere too.

User demand is roughly but not exactly covered by adoption - you sometimes need to work on some issue to help existing users, even if it may have no impact in terms of increased adoption