-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdecision-making.qmd
108 lines (54 loc) · 7.7 KB
/
decision-making.qmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
# Decision making
::: callout-tip
## Lesson objectives
In this lesson we'll discuss decision making for your project. How can you determine how you make decisions? Resolve conflicts? How do you communicate with others how you make decisions?
:::
Like any project, for your open source project, you need to make decisions about what to do, what to implement, what not, how to go about it, how to document something, or what language to use in an error message. Unlike some other projects you work on though, all the decisions you make are made in public. Therefore it's useful to have a framework for how decisions are made, so people don't just see a decision, but can see some of the process that you used to get there.
Decision making has a 'who' and a 'how' component.
Let's start with 'who'.
## The 'who' of decision making: governance
Governance is decision making. You set up governance structures, so you can make decisions for the project. Here again you need to think about project goals.
I’ll start by being a little controversial here. You don’t always need a governance structure. If it’s just you working on the project and you’re making all the decisions, and it’s at an early lifecycle stage, that’s probably fine. That’s maybe less fine as the project beomces more central or other factors though. And here’s where I back off from that initial controversial claim. We can rephrase it as a single person making decisions is its own form of governance. We just don’t often think about it that way.
So, let’s talk about a few differnt models.
### Single maintainer
So, it’s just you. You’re the primary contributor and docs writer and all the things. So, clearly you make all the decisions and everyone knows that, and it’s fine, right. Alas, no, 1) some people might not know that and 2) you still need to decide and communicate how you make decisions. Think of future you here, will you understand how past you made decisions.
There’s not necessarily an obvious file or section to write about a governance model. However, you won’t have much to write here, so you could include some text in your CONTRIBUTING.md, even though someone could figure it out from the github information, like
> PERSON is the primary maintainer for this project. Decisions for the project will be made with (list or link to project goals) in mind and the need for continuing maintenance on the project. The project also needs to stay compatible with X, Y and Z.
> If you'd like to propose a new idea for the project, please share it an issue for discussion.
Again, this will be something you can point back to if, e.g. someone puts in a PR that’s out of scope or will be hard to maintain.
### Multi-person project
You’re growing or started this project as a collaboration. The main thing you need to do is make some decisions about how you’ll work together and make decisions. There’s a lot of models for this.
Red Hat has a nice overview of six different models.
[Understanding open source governance models](https://www.redhat.com/en/blog/understanding-open-source-governance-models)
### Multi-stakeholder project
How is a multi-stakeholder project different than a multi-person project? It’s different because you are at the stage where you have multiple types of stakeholders - users and contributors who may have competing needs or interests, and resources to put behind these different interests. This is where governance really shines. You need to be clear about how decisions for the project are made that serve the community as a whole. Otherwise you can end up in situations where work gets done just where people can put effort, and that might not be the top set of priorities for the project as a whole.
::: callout-note
## Exercise
In your project, who makes the decisions? Draft a couple of sentences about who makes the decisions for your project. This isn't something you'd necessarily share yet, it's a first draft for your own clarity. Pair up and talk about this with a partner.
:::
## The 'how' of decision making
Once you know who is making decisions, you can think about how you make them. What input do you include, what rubric do you use for making decisions (even if informal)? Having project goals and knowing roles within the team can already have put you on a path to make this process easier.
::: callout-note
## Exercise
How would you say decisions are made on your project now? Write a couple of sentences that describe how decisions are made. What's clear about your decision making approach? What could be clearer?
:::
### Resolving conflict
You have some clarity on who makes decisions and how, and that's a big help! There will always though be disagreement, either within the group of decision makers, or with community members. So how do you resolve conflict? This is one of the top thing we're usually uncomfortable with. Conflict isn't always bad! It can help us get to better ideas, but it isn't usually something we look forward to encountering.
In this section we'll focus on conflict with contributors or users, because this is conflict that is usually in the open in open source projects, which adds some additional layers.
There's a few steps of assessment and responses you can go through.
- Step 1: Is this a new person to the project?
- Is this a person new to the project who might not know about how to contribute or how decisions are made? If so, reply to the person kindly pointing them at these resources and ask them to follow the approaches you use, and help them in the process.
- Step 2: Is this a new issue with an existing person or team?
- If it's a new issue, approach it with a decision making approach based on project goals, here talking through reasoning can be helpful for a shared understanding. Start with asking questions so you understand.
- Step 3: Is this an ongoing issue with a person or team?
- Here is where the issue isn't really about the issue. How can you understand this person's general perspective, or realize that there's not good intent on getting to a shared understanding?
::: callout-note
## Exercise
Scenarios: These are a few scenarios. Pair up with someone else and choose two scenarios. In one you'll be the project maintainer and the other person will be the contributor, and then change roles for the other scenario.
**Scenario 1:** A new contributor submits a pull request to your repository. It's quite a bit of code, adding in a new feature that hadn't been discussed before. It's on topic, but not aligned with your current goals for the project, or the resources you have available.
Reply in this [pull request](https://github.com/posit-conf-2023/managing-os-project/pull/2) how you would for your project.
**Scenario 2:** A frequent contributor submits an issue that something isn't behaving the way they expect, and suggests a new approach. They've submitted helpful PRs in the past.
Submit and respond to an issue in [this repository](https://github.com/posit-conf-2023/managing-os-project/) how you would for your project.
**Scenario 3:** Someone frequently submits issues in your repository, and communicates in a way that suggests things need to be fixed, in a way that works for them, right away. One person submit an issue that takes that approach and the other person respond, by creating an issue in [this repository](Submit and respond to an issue in [this repository](https://github.com/posit-conf-2023/managing-os-project/).
**Scenario 4:** A frequent contributor consistently submits PRs without discussion, on things that aren't aligned with project goals. There's clearly misalignment with either the project goals or there's some interpersonal issues. In this scenario, don't do it through an issue or PR, have a conversation with your partner.
:::