Avoid loose ends & be deliberate about decisions.

In order for us to be able to harness the creativity and input from Gitpodders effectively, we need to make sure discussions in our tools, be it Slack, Notion, GitHub or in meetings lead to clear outcomes. Otherwise, previously spent effort is wasted and we create lots of loose ends, ambiguity and misunderstandings, leaving people unclear about next steps.

Even spontaneously emerging discussions (e.g. in Slack) about certain topics and issues should be channeled into concrete next steps and decisions (a decision that there won't be next steps/actions, is also a decision!). It's the responsibility of everyone (see Managers of one).

Even if you are not the one who can make the decision, it is okay to nudge the ones who are and ask about concrete next steps and how the discussion will be taken forward.

Since we are fully remote and favor an async collaboration model, making decisions also heavily relies on written information. Why? This makes the process more transparent, thought through and inclusive, as not everyone is as comfortable speaking up in meetings and because not everyone is able to join meetings due to vast timezone differences.

As a rule of thumb, if an issue or decision **is stimulating a conversation, that’s a good indication that we should start writing things down. A very lean but well suited way of doing that is to do a Request for Comments (RFC) 👇

Request for Comments (RFC)

Creating your first RFC (video)

These documents are short write ups to help us get to a decision faster, more collaboratively and transparently. They live in the ‣ section in Notion where a template is also provided. See Templates & Template Buttons for how to use & create templates.

In order to be effective, it is important to capture the following points in an RFC:

1. A (detailed) description of the issue: this avoids confusion and back and forth
2. The desired goal: Keeps you honest and lets others in on what you are trying to do
3. A proposed solution:"I don't know the answer" doesn't count - take a guess 🔮, this will trigger conversations much faster
4. Next Steps / Decisions: That's the purpose of the RFC, so make sure to write it down once it's been reached
5. Notes/Resources: Relevant docs, links, GitHub issues, Slack discussions or other resources

No need to make the RFC perfectly beautiful before sharing it - just make it good enough to convey your point.

When to do an RFC?

• There's a topic / issue with bigger discussions in meetings or threads, or it comes up repeatedly (e.g. ‣)
• Bigger topics that affect several teams or the product / users in a greater way (e.g. ‣)
• You have an idea that you want to socialise and get feedback on (e.g. ‣ )
• Reversibility of the decision: If the decision is hard to reverse ("no is temporary, yes is forever") and potentially far reaching (e.g. new features which will be hard to take back)
• As a "decision log" through pasting some context from the relevant discussion for a decision that has been made without the regular RFC process

When not to do an RFC?

• Implementing the idea is faster than writing the RFC and things mentioned on the left do not apply 👈 (e.g. propose a change in the handbook)
• Minor, less complex topics that may be more binary (e.g. should we upgrade BirthdayBot?)
• A small, local decision has been reached already through a discussion

The phases of an RFC (reflected in the status attribute)