-
Notifications
You must be signed in to change notification settings - Fork 2
Change Process
So you have an awesome new idea for how to improve Prog Code but aren't sure where to begin or how to get it done? Despair not, you've come to the right place! This guide here will help you understand everything you need to know, from initial conceptualization through implementation and continual improvement. Like everything else in Prog Code, this is a continual work improvement, so if you have an idea for how to improve please let us know. And if you're still not sure what "let us know" actually means, then read on!
First things first, what is a change and what is its significance? Well, from a philosophical level, change is everything. From the very first single celled organism to the highly flawed species who created all of this, we are a product of continual change. But on a more tangible level, though remaining true to form, change is how anything gets done, especially in a community like this one.
So, regardless of whether you have a brand new project idea, an improvement to an existing process, or a new system you want to try out, what you ultimately want is change. Change is especially important for an idea-driven culture like ours, where we encourage one another to nurture trying new and exciting things while having the right process in place to ensure chaos doesn't ensure due to the change.
So, now that you have the background to how we think about change, it's time to put that into practical execution. As mentioned, the first major step is actually understanding what you want to change or improve; perhaps there's something you used in a different group that could benefit us here, or there's an unnecessarily bureaucratic process that could be simplified. Once you know what it is, it's time to get buyin. As we operate in a "Sociocratic" model, the focus is ensuring the community and team agree of the change's viability, rather than one individual. Finally, once you know your idea and have gotten buyin, it's time to implement and document the change. We'll get even more specific for what this looks like in the next step.