As stated above the milestones are these defined things that teams decide together through a process, the idea it to celebrate achieving a milestone. As Scrum teaches, the most important part of the process that allows for teams to self organize around milestones is to allow for an empirical study of the actual process. Whether or not the milestone was accomplished, the whole point is not to achieve meaningless milestones and have a party. The point is to refine the process so we can learn and grow as empowered individuals.
I think we are all already know the existing approach of managed development cycles.
So I would focus on difference between SODC and the legacy one.
Where do you see the difference to existing management approaches?
What would you emphasize?
Personally, I see the main differences being that beyond our own development cycle to coordinate, we must coordinate with the larger open source community. Collaboration as a principle of SODC is crucial for an effective development cycle to be part of the larger community. What do you think @Ethernian?
We just had our first call here between me and Aidan (ChainSafe)
5 Likes
thinking about it but… still unsure we have something really new here…
Why one SODC should coordinate with other SODCs in the larger open source community? What is the reason? I don’t say there is no any, but I would say, we need to point out the reason explicitly.
Is it because others are developing libraries one depends on? Or you mean there is reason of higher level for coordination? If parts should fit together and this is our goal, so may be we are missing some role like Product Manager (or Program Manager - for bigger cases)? Then we should try to adopt this classical role to our reality without reinventing the wheel.
From other side: there are bigger projects in opensource community releasing products based on work of many SODCs. For example, there are linux distributors, like Canonical with Ubuntu. Do we missing that part in our ecosystem?
I would prefer to find and adopt existing experience instead of reinventing the wheel.
I think community calls like the Plasma Implementers Call, show how neccessary it is for SODCs to coordinate with others SODCs. I agree that we should be more explicit about how we make that clear, any ideas?
To answer all your questions, I would say that in blockchain it is much more than just depending on one another. It is about realizing that only together can we solve these problems. My big concern is that when we realize a lot of these projects we won’t continue this open collaboration. In regards to the specifics, I would say that specific roles like a PM are not necessary to specify as SODC to me is more akin to Agile Principles than a Scrum framework. This is not about reinventing the wheel, we have already done that by partaking in the web3.0 paradigm. This to me is about making observations based on what we do and are doing and trying to create principles around it.
It is the adhoc nature of these self organized calls like the Plasma Implementers Call that makes this process so unique. A lot of the time members of the Ethereum Foundation are involved, but it is individuals that have decided to self organize in these working groups.
Everything I have written has been inspired by the manifesto of agile software development, not sure what you mean by reinventing the wheel. This is just building on pre existing processes in a way that tries to capture the nature of development cycles in web3.0.
Thanks for the feedback!
I’ve been on planes over the past week - touched down in Toronto. Going to meet up with @ChainSafe tonight for anyone else that will be around.
1 Like
BlockquoteWe just had our first call here between me and Aidan (ChainSafe)
Super fomo!!!
1 Like
Please see my replies inline 
Thanks for the feedback, this is awesome!
Yes, a request of information was intended to be the example of something not to say no to. The way I have seen a natural way to “say no” is by having different spaces for people if they want to be left alone. We have a quiet room that has space for anyone looking to be left alone. For people without the space I have heard people use signs for a similar outcome. How do you think this principle could be updated more explicitly to get the message across?
I absolutely agree, how do we update the principle to reflect this?
That is what I see these principles as, a framework could be built on top of this to specify things in more detail.
Absolutely!
Totally, this is scrum 101 and something people who preach scrum don’t highlight enough.
1 Like
To continue the detailed conversation, here are some comments/questions:
Objectives
- provide resources to self-organising groups in the web3 domain
- resources created from learnings from other open-source projects/products
- highlight differences between web3 projects/products
(feel free to amend)
Some standard definitions
Product Manager - creates vision, roadmap, and backlog of high-level features/epics
Project Manager - facilitates flow of tickets through sprints
Some questions/clarifications
- Products often conventionally from the point of view of end-user products being built by a hierarchical organisation, what considerations/differences need to be taken into account for open-source web3 products?
- When the product is a protocol, the users of it are often developers (who are likely to be working on an open-source web3), how far do protocol developers go to anticipate end-user product-needs, and how these might feed into the protocol?
What do people think?
2 Likes
Great feedback!
I think a major difference is the process in which these products are built. Our only user facing product is a wallet app which we started at ETHDenver and have been building out ever since. We plan on integrating different layer 2 projects, meaning we have to be aware of the current research and development that is out there and potentially work with different teams to help us integrate these features. I believe this is a unique aspect of the web3 product domain, what are your thoughts?
I think as protocol developers and or people who build developer tools, we need to always think about how real people will end up using these things. If we do not allow for features that developers want to build for users to be a part of our tooling, I believe we are failing. This means working with developers to make sure we are building the right things.
1 Like
Agreed, the movement of underlying dependencies is more rapid in web3 than regular open-source development. To add to the question, I’m also wondering if the decentralised ethos comes into play when developing products.
For those making a product for the sake of a token jammed into it, we’ll probably see the same centralised product decisions being made. But for those building for the decentralised future, I wonder how product decisions and vision differ. Would open-source DApp developers prefer making white-label products that can then be branded by anyone who wants to use it (whilst still giving credit where it’s due), or is that too idealistic an assumption to make?
Also how developers in this space take to familiar product visions vs more ideal decentralised products, and where this touches upon feasibility. Plenty to ponder
1 Like
That’s the nature of open source, I think this is an important aspect to the principles of an SODC.
Totally, we should talk about this in the next ethproduct call.
Hey everyone, please find the first version of our principles live at sodc.io!
It lives as a github page that can be updated here. This should not remain on my personal account. It would be nice to transfer the repo over to the FEM org or to make a new one.
Let’s continue making them better and maybe start discussing what a few pillars might be throughout the principles.
4 Likes
Its awesome! How do we go about testing, validating and improving this?