I merged my notes into yours
Yup! after some traction think we can def add it to the scroll wiki
Great to meet everyone today. Some problems defined that we are trying to solve
Hard to understand from the outsider where to go if you want to get involved…intimidating
How do we onboard new developers? Good first issue
Mass adoptions should be part of ethos
Education should be on everyone’s mind, what ever you do should be teachable to someone else
1 Like
What is our ideal 10 out 10?
My 10/10
Defining a philosophy that enables decentralized development cycles. Important things for me as part of the definition:
- allow people from multiple timezones collaborate efficiently
- allow people with different commitments collaborate
- create a framework that encourages knowledge sharing; this is important to increase the bus factor
- allow people to gather knowledge that is auxiliary to the work they actually do
2 Likes
Hey folks! I am trying to begin drafting a skeleton for the manifesto from the notes and I thought it would be pragmatic to start with principles similar to the manifesto for agile software development. Please let me know your thoughts and what to change/add to. Hopefully together we can get some of this preliminary work done and then we can start having bi-weekly (twice every month) calls to get things going. Thanks @noot for helping proof read this 
Principles of The Methods for Self Organized Development Cycles (SODC)
- The highest priority is communication followed by process.
- Sharing knowledge by never saying no, always empowering individuals to participate in discourse.
- Self organization looks and feels different to different people, defining process and methodology for organizations is vital for decentralized development cycles.
- SODC is about the people; user, developer, designer, etc… needs come first.
- Inclusiveness as a mechanism for realizing individuals and collectives perspectives transparently.
- DoAcracy as a method for creating self determined and self regulated development cycles. This allows for the individuals of an organization to take responsibility for their day to day tasks through a self determined process.
- Milestones are a crucial aspect of SODC, allowing for team accomplishments to be celebrated. Whether the milestone was completed or not, the aim is to allow for an empirical study of the current SODC process being implemented.
- A transparent and open process between all aspects of the development cycle is expected. Ensuring research, design, implementation, etc… are all working together and not against each other.
- For SODC to be effective, it is important to collaborate with the wider open source ecosystem. Separate teams working on similar, dependent or complementary works should collaborate and share knowledge for the benefit of the larger community and in turn as members of the community help themselves optimize their development cycles.
- In SODC teams operate by respect, not rank.
- Teams must come to consensus on the definition of done, for clear outcomes to be understood by the entire team.
8 Likes
Hey all, bit late to catch up with this thread but still super interested to see what we come up with! Some great stuff above already.
Points about communication and knowledge sharing remind me very much of some writing done around remote teams. I can’t find exactly the post I’m thinking of, but a quick search finds many including stuff about async communication, “when one person is remote, everyone is remote”, etc. I’ll try and find the one I have in mind and post here. Possibly existing ideas for remote teams could act as a good basis.
2 Likes
Reading through this quickly while I wait in Heathrow for my flight to Denver. It’s fantastic. A question I discussed with several people at Devcon was how to maintain coordinated development without the hierarchy of management used within corporations. One insight that came up is that the best managers operate by respect rather than rank.
4 Likes
Thank you for the feedback . I will add that point to the principles!
I would really appreciate feedback from other people that attended the ring (or anyone else! didn’t mean to exclude anyone)
Not sure if I am doing justice to the conversation we had.
1 Like
Thanks for putting this together @ChainSafe!
Since we have to account for quite some remote team, I like that communication is on top of the list. I think it cannot be underestimated.
Who do we see as “developer” here? Really only the people coding? I would suggest to open this up a bit and also include e.g. (UX) designers and their needs, since their work is crucial for adoption and especially frontend dev teams usually have quite some dependencies to them. What do you think?
It’s super important to have them stored in one place and have everyone be aware of them. I have seen this too often in the past, that some people weren’t aware of the importance of some features and what it means for them to be done.
1 Like
Thanks for the feedback @tschubotz!
You are absolutely correct, this should include the whole team and not just developers. I will update this principle to reflect a more inclusive definition of people.
Totally! It is crucial to maintain a team definition of done, as this determines the outcome of a development cycle. I will add that to the list of principles.
Thanks again for the feedback, this is extremely helpful!
Many teams work almost entirely via proprietary, conversational channels like Gitter and Skype, with little to no support for threading, searching and archiving, and inadequate (if any) integration with email. This makes working across time zones difficult for even small teams, and doesn’t scale to large teams. It hurts your other desiderata as well, as those not collaborating frequently, or simply seeking knowledge, will find themselves lost in a long thread of disjointed conversations.
2 Likes
What have you seen work in these situations? Also, what would you say could be added to the principles to help people understand the importance of communicating through tools that work with an SODC? Thanks.
One startup founder put it well: “Every decision someone has to make is the lack of a guiding principle”
Setting the right principles from the outset will help get a lot more done. The list above is a great start.
I think ‘contributer’ could include everyone relevant in this context.
For clarity, what do you think of prioritising either users or contributors so when a decision that may affect both stakeholders comes along, the principle makes it an easy choice?
Really excited and inspired to see this emerge. And I need this in so many projects I am involved in!
One thought I have is the use of the terms Self Organization and Decentralized. I see why it is important to call out the key principles/methods of this initiative w/ the acronym SODC. But as this initiative starts to form an enduring Ring, perhaps the name of the Ring should only reflect the most essential part of the problem domain that is being addressed. Perhaps then: “Development Cycles Ring”.
Using a short name for the Ring makes it a lot easier to refer to, and makes it more accessible to newfolk. The Self Organized Development Cycles acronym and other terminologies can be used in the writing once the reader understands the bigger picture.
As people get drawn in, they’ll begin to pick up on the principles and methods… and if they’re in Ethereum they’ll probably already have a lot of that baked-in!
2 Likes
Great name for the ring! It is very important not to scare people away with unnecessary jargon. Thanks for the feedback. I will change the name of the post to reflect the ring name once everyone agrees!
Great start and love the points on autonomy. I’ll take stab at shortening the manifesto.
1 Like
Great idea.
Throwing out some more possibilities:
- Decentralized Development Ring (DDR ha!)
- Ethereum Agile Ring (EAR heh)
- Autonomous Development Ceremonies
- Decentralized Agile Ring
@ChainSafe - I’ll setup a weekly call and let anyone join. What’s the best way to get everyone’s email?
Cyrus