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.
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.
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!
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!
Reading through this I have a question, what is the base type of workflow we are trying to address? Is a team being decentralized a necessity? Is agile, autonomous or distributed teams also a factor? I think @jpitts suggestion for calling the ring “Development Cycles Ring” does a great job of addressing the fundamental unifying characteristic between all decentralized, distributed, autonomous or agile teams which is the development cycle itself. SODC does not necessarily need to define this ring and I foresee many manifestos and educational materials being created for different types of teams.
A weekly call would be amazing! Instead of rocketchat could we use riot.im? It’s basically like gitter so conversations can be open to the public. Though I really like using the FEM discourse so people not fully active in the ring can still participate. We could also have a live streamed zoom call that we coordinate here or even create a github org so all our info can be public and forkable/maintainable by anyone.
Blockquote
Reading through this I have a question, what is the base type of workflow we are trying to address? Is a team being decentralized a necessity? Is agile, autonomous or distributed teams also a factor? I think @jpitts suggestion for calling the ring “Development Cycles Ring” does a great job of addressing the fundamental unifying characteristic between all decentralized, distributed, autonomous or agile teams which is the development cycle itself. SODC does not necessarily need to define this ring and I foresee many manifestos and educational materials being created for different types of teams.
Good question. In my opinion it is about synchronization and knowledge sharing of any type of Ethereum development wether it be agile, scrum, waterfall, distributed, etc.
