Change Process

Overview

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!

Introduction

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.

Getting Started

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. 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.

Change Process

Major Changes

1. Create a GitHub issue, including:

• Description - what is the actual change?
• Problem - what issue does the change address?
• Function - which functional area does this impact?
• Benefit - why should we do this?
• Plan - how will we do this, what's updated?
• Decision - how will we decide to implement the change?
• Resolution - what is the outcome following the change?

NOTE: if you're unsure about any of the above, give a shout in #ask-the-team. If you want to find out if something is already under way, check out our GitHub repo in Step 4

2. Discuss your change in the appropriate functional channel. If you're not sure where that is, #operations is always a safe bet
3. By EOD Saturday EST the meeting facilitator will send an email of the agenda with all the items listed in the ProgCode 4. Volunteer Staff Weekly Meetings to the people in the #operations channel
4. Ensure major changes are introduced in previous week’s volunteer staff meeting to receive consent to proceed
5. Following consent to proceed, ensure major changes are finalized in GitHub five days prior to volunteer staff call if requesting consent to implement
6. Post major change in #operations, notify anybody listed as a GitHub coordinator in Slack
7. After reviewing, discussing and coming to consensus about the suggested change, the person suggesting the change will describe their change, then decide whether to put it up for a vote as part of the weekly volunteer staff meeting. They should not be anonymous and should put +1 / -1 / ~ as vote
8. If voting to block or abstaining, provide terms that would turn your vote into consent
9. By EOD following the meeting the facilitator will create a new GitHub issue highlight all action items with owners, giving anybody not in the meeting 72 hours to vote on review, comment and vote on open issues
10. Previous actions are reviewed at the beginning of every weekly staff call

Standard changes

Standard changes are any frequently repeatable changes to existing ProgCode services and functions. These changes should still be visibly documented, however should not require the complete change and decision making process. These changes should have low potential impact to ProgCode core strategy and objectives, while any person should be able to recommend changes.

1. For the first time a standard change is established, follow the existing change and decision making process, indicating that this will be a standard change.
2. Once approved, update the change with a table to track proposed changes with submitter, date, and reference link
3. An example use case for this is making updates to the ProgCode Toolkit
4. Standard changes should be tracked in its own column in the ProgCode functions board
5. Description includes a running list of times the change has been implemented, with information including: Owner, date, comments, improvement suggestions.

Decision Making Options

Consent to proceed

Requires unanimous approval/abstain decision votes to continue exploring, useful for building a team and gathering interest/buyin in a change you believe would be valuable. Can be used for brainstorming and to ensure team is bought in early in the process to maximize collaboration. If somebody does not consent, they must provide feedback to address that would enable them to consent.

Consent to implement

Requires unanimous approval approval/abstain votes for approving the change implementation based on the GitHub issue. If somebody does not consent, they must provide specific changes to the implementation plan that would make them consent. In the event of a continually blocking vote, the change owner may put up a vote to overturn, used only in extreme cases and requiring 80% approval.

Volunteer staff supermajority

Thumbs up or thumbs down vote, requires 65% of volunteer staff members voting in favor with at least half of functional contributors/coordinators voting. Poll posted in #operations. The vote occurs as defined in the GitHub issue and steps 6/7 in the above Major Change section.

Community supermajority

Thumbs up or thumbs down vote, requires 65% of community members members voting in favor. Requires at least ten total votes to count, poll posted in #community-vote as described in the GitHub issue.

Conclusion

And there you have it, easy enough, right? If you've followed these steps you are officially on your way to being a champion Prog Code contributor, nice work! And for extra credit, maybe reading through this process you've noticed a TON of open holes that you want to help fill (e.g., where do we document processes, how do we track what needs to be updated for a change). If that's the case, feel free to return to step 1 and start improving the Prog Code community. Remember, everything starts with an idea, however ideas are strongest when they're nurtured and improved by a broader community, so no worries if you're not certain how to do everything on your own; that's exactly why we've been building this amazing community with an incredible diversity of skills and an eagerness for continual improvement.