Design Guide Release Cycle Structuring

[pavlenex]

This is a detailed breakdown of the release cycle i brought up in community call #8 and jam session #1. The goal of this discussion is to try to evaluate whether or not the release cycles should be introduced for the design guide. and if we decide to proceed with the idea, how to structure it.

Please bear in mind I've structured this according to my experience in FOSS. Obviously the release process should be adaptable and help us work better together. Like any good process, it should be there for people, so it's essential that if we decide to proceed with this, we make sure that process works for us, not the opposite. That said it's crucial that we all brainstorm the ideas, processes and tools that can help us wort better together. Your feedback is appreciated 🥇.

Overview

The Bitcoin Design Guide is still in the conceive phase. After quite a lot of hard work & research it's time to start preparing and get the MVP out there. We discovered that some parts of the guidelines overlap. Community is still unaware of any progress we're making, and it seems that general impression is that we finally should put something out there and celebrate, because let's face it, even though it's not visible, contributors here have so much to share. So let's begin sharing. Small incremental pushes that are ironed out along the way without the fear of being perfect are what makes FOSS great.

The problem

• It's not always clear who's working on what
• There's overlap between certain parts
• Community isn't aware of any progress we're making
• Pull requests in this early phase are big and take lots of time to review

What is a release cycle

• Definition of a release cycle.
• What is a GitHub release

Who defines a release cycle

The release cycle is determined by most active contributors. In FOSS, meritocracy should be the factor that determines the contributors who should be in consensus.

Adapting the release cycle

The release cycle I described mostly happens in software development, like any good process it should be adapted. @danielnordh had a good question on how we can better adapt this for designers, and I would appreciate some ideas there as well. My idea is that everything happens on GItHub, since it' currently the best free collaborative platform out there. It also has basic but good enough tools for us to manage a release cycle.

Steps needed to establish a release cycle

1. Have minimal viable product out there (MVP)
2. Define a release branch on GItHub (master/stable)
3. Define a time-frame for release cycle (2-3 week sprint?)
4. Define the process (Set up the project in GItHub projects)
5. Define person(s) that would help with issues management on a kanban board
6. Document the release cycle process for transparency

The process

0. All the actionable issues and ideas from discussions are turned into GItHub issues, regularly discussed, available for community to review and add ideas. Issues are based on contributors ideas but also on feedback from community and people using the guide.
1. Team of core contributors meets up and decide on what issues should be tackled and suggests some additional stuff.
2. Document all issues into steps and assign them to contributors
3. Add issues into the GitHub project and create a timeline for the sprint.
4. If needed organize another meeting to check back on the progress so that everyone are in sync
5. Review pull request & Test.
6. Draft a release
7. Announce and celebrate

Example of a release cycle

1. The team of core contributors joins the focus meetings, reviews the issues on GitHub and each member talks about what in their view is important thing needed for next release. The release can be wrapped around certain use-case, for example in this release we want to help XYZ wallet create a good backup process, so we want to have all documentation needed for that.
2. The project titled v0.01 is created and all the issues are added into it.
3. Issues are assigned to contributors
4. We determine the time-frame and create the project
5. Every contributors work focused on the issues assigned to them and once we have a way to resolve it a pull request is opened.
6. Pull request is reviewed
7. Once reviewed pull request is tested locally
8. Pull request is merged and issue is moved from In Progress to Done (automatically)
9. Once all the issues are Done, we test the features once again
10. When final test is lead maintainer, drafts a release
11. Changes are then pushed to the guide where people can preview them
12. We create release notes/blog post/video and inform people on the new features if
13. We celebrate with community and await for feedback 🍾 🥳 🎉 and then re-do 🔁

Pros and Cons of the release cycle

Pros

• Frequent releases
• Smaller pull requests and easier review process
• Informs community on our progress
• Creates a sense of achievement and allows us to celebrate our great work 🍾

Cons

• It's a trial and error and there's no a perfect formula. It will take time to perfect the process
• Designers may not be familiar with releases
• Formal structure may put off some contributors

[GBKS]

Love it, thank you for pushing this topic. We can probably create a document like the one on the project life cycle.

A few unorganized extra thoughts, including some from yesterdays conversation:

• This could be synced with the newsletter and the community call which already happen every 3 weeks
• We need to consider "deliverables" that do not live on Github, like Google Docs and Figma files
• Tasks will change and get more detailed over time. Right now we're adding whole sections and pages, at some point it might be translations or lots of minor revisions. We may just want to allow for some flexibility
• It should be clear that these release cycles only affect guide work and not everything the community does. Nobody should feel restricted by this, as in not being comfortable working on their own design project
• We should create our own definition of "testing changes". For us it will be things like copy following the content guidelines, avoiding overlap and contradictions with other pages, some way to evaluate illustrations, etc
• We need to be sensitive to the availability and plans of individual contributors
• What does success look like? How do we know it's working?

[pavlenex]

It should be clear that these release cycles only affect guide work and not everything the community does.

I agree this is very important. We should encourage and aspire people to pursue their own projects and initiatives since the design community is not just working on the guide. Would be good to find parts where onboarding interested members to the guide would be easy. The work on guide requires previous experience in Bitcoin and technical knowledge, but a good way to engage people would be to have community creating educational content for Twitter where we can share small chunks of educational content for newcomers. "What is a transaction", "What is an UTXO" and it can all be visually displayed. This way designers themselves can learn about bitcoin as they work on interesting graphics/animations that can help educate wider audience.

We need to consider "deliverables" that do not live on Github, like Google Docs and Figma files

Good point. Personally I see no reason why GItHub and Google docs should be disconnected. It's okay for people to prefer to write in google docs but when the work is ready, it always goes in form of a pull request anyway.

We should create our own definition of "testing changes".

Good point.

What does success look like? How do we know it's working?

In my opinion success would mean that contributors are in sync, aware of the structure and work of other contributors and that smaller chunks of work are constantly delivered and ironed out based on feedback. Also, people get to see their work in the wild more often and get feedback or appreciation which is important for motivation. The visible result would be work constantly being delivered, tested and ironed out and more engaged community. How do you see success yourself @GBKS ?

[GBKS]

I find success in these things tricky to evaluate. It's like when nobody notices that an event is well-organized because they are just having a good time, even though a huge organizational effort happened behind the scenes. Or when you don't get any feedback and you're wondering whether nobody cares or they deeply care but are just happy with how things are going and don't have much to say because of that. It can be tricky to evaluate objectively. But your description is spot on, and constant communication is probably the only way to keep things going in the right direction.

[ConorOkus]

I think this is very cool @pavlenex .

Having every release accompanied by more in-depth material notes/blog posts/videos/tweets etc sounds like a really good idea.

On the sprints, would we be quite rigid with it and only bring in what we feel we can complete or is it more of a tracking mechanism for the releases so we know what has been completed and is ready to go out in that release?

How have planning sessions been in your experience when deciding how to prioritize issues?

I'd be willing to try it out and see how it goes.

[pavlenex]

I am personally not a fan of rigid sprints. Ideally, us detecting realistic goals and trying to stick to them would be good, but we should adapt. For example, during the sprint we can easily add/remove issues on a go. In my experience, while the core goals are rigid (in this release we'll try to have Private Key Management Section published) the tasks around those goals are flexible.

How have planning sessions been in your experience when deciding how to prioritize issues?

On projects I've been to, it's usually handled by the team of core contributors. People who spend every day contributing and being involved in community. Meritocracy chooses the core team and people who invest significant time into a project know it the best and care for it's success the most.