Thank you everyone for today’s conversation, excited to see where this all goes.
Please add your notes and comments here 
6 Likes
Hello, excited to see this group grow!
2 Likes
Hey all 
Here’s my doc of taking some notes of the Ring discussion in Prague: Way of self organization in decentralized development cycles - HackMD
Feel free to contribute and add things
4 Likes
Here are links to similar discussions / topics:
-
See here for problems and solutions while creating a list of people in decentralized:
Create List of Architects -
Problem of local knowledge covered here
It is not 100% hit, but I mean good discussion point
2 Likes
Hey, happy to be a part of the discussion today. Waiting for the Manifesto Draft.
Could this be pushed to git? In my view it’s much simpler to collaborate and discuss before it’s finalized
Great idea, a way of doing that could be by attempting to formalize this as a ring to be added to the scrolls.
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.