Archived
15
23
Fork
You've already forked meta
6

Document decision-making process #148

Merged
fr33domlover merged 1 commit from fr33domlover/forgejo-meta:dm-guide into readme 2023年03月02日 16:04:56 +01:00
Contributor
Copy link

So far, the decision-making guide is a brief very simplified one.

This PR:

  • Improves the simplified guide
  • Adds a full detailed version of the decision-making process, to help everyone make non-trivial decisions together, and so that even if I disappear, the project has the tools to continue, learn, evolve, flourish
  • Tweaks the table in AGREEMENTS.md based on earlier feedback

Clarification: This PR isn't making a new agreement/decision, it's mostly just expanding the decision-making guide, and we can continue to try the guide in Forgejo and see how it goes and improve it as needed. Or even throw it away entirely if it really doesn't work.

It's not a command forcing you to make decisions in a certain way. It's a helpful resources giving you a way to make decisions together. If you know what you're doing and you don't need a guide, that's fine.

The Request

If you have limited time to read the guide:

Can you skim through it and see if there's anything that stands out, that bothers/concerns you or that you disagree with? And comment if yes. Otherwise, do you trust me and willing that we try the guide in Forgejo (despite not thoroughly reading it) and see how it goes, and let it improve via ongoing feedback, and make an official community approval at a later time? (Worst case, if it turns out to be garbage, we can delete it)

If you don't have time to read the guide:

Do you trust me and willing that we try the guide in Forgejo (despite not reading the very long detailed sections that this PR adds) and see how it goes, and let it improve via ongoing feedback, and make an official community approval at a later time? (Worst case, if it turns out to be garbage, we can delete it)

If you have time to thoroughly read the guide:

Can you go through it and review / give feedback? Including questions if there's anything there that's unclear or confusing.

If you don't have enough trust in me to answer yes to the questions above, that's fine and please don't hesitate to say so <3 I know it's hard to trust a stranger landing some huge document out of nowhere. We'll figure out a pathway to togetherness. Even if it means simply closing this PR without merging anything.

So far, the decision-making guide is a brief very simplified one. This PR: - Improves the simplified guide - Adds a full detailed version of the decision-making process, to help everyone make non-trivial decisions together, and so that even if I disappear, the project has the tools to continue, learn, evolve, flourish - Tweaks the table in AGREEMENTS.md based on earlier feedback Clarification: This PR isn't making a new agreement/decision, it's mostly just expanding the decision-making guide, and we can continue to try the guide in Forgejo and see how it goes and improve it as needed. Or even throw it away entirely if it really doesn't work. It's not a command forcing you to make decisions in a certain way. It's a helpful resources giving you a way to make decisions together. If you know what you're doing and you don't need a guide, that's fine. # The Request If you have **limited time to read** the guide: Can you **skim** through it and see if there's anything that stands out, that **bothers/concerns** you or that you disagree with? And comment if yes. Otherwise, do you trust me and **willing that we try the guide in Forgejo** (despite not thoroughly reading it) and see how it goes, and let it improve via ongoing feedback, and make an official community approval at a later time? (Worst case, if it turns out to be garbage, we can delete it) If you **don't have time to read** the guide: Do you trust me and **willing that we try the guide in Forgejo** (despite not reading the very long detailed sections that this PR adds) and see how it goes, and let it improve via ongoing feedback, and make an official community approval at a later time? (Worst case, if it turns out to be garbage, we can delete it) If you **have time to thoroughly read** the guide: Can you go through it and review / give feedback? Including *questions* if there's anything there that's unclear or confusing. If you don't have enough trust in me to answer yes to the questions above, that's fine and please don't hesitate to say so <3 I know it's hard to trust a stranger landing some huge document out of nowhere. We'll figure out a pathway to togetherness. Even if it means simply closing this PR without merging anything.
fsologureng left a comment

This for now 👍

This for now 👍
AGREEMENTS.md Outdated
@ -10,0 +11,4 @@
- **Where to document agreements:** When a decision is made, and it includes an agreement about how we do things, the person who initiated the decision records the agreement as follows:
- If it's within a specific team, it goes into that team's agreements file
- If it's a change in the roles of team members, update `TEAMS.md`
- If it's a conceptual agreement about our values, it goes into `VALUES.md`

I understand yo will change VALUES.ms by MISSION.md. The change will be done after the other change have been merged?

I understand yo will change VALUES.ms by MISSION.md. The change will be done after the other change have been merged?
fr33domlover marked this conversation as resolved
AGREEMENTS.md Outdated
@ -10,0 +21,4 @@
1. Domain: Type of decision / domain of responsibility
2. Who decides / Who is accountable
3. How? Based on what? Advice, policy, criteria
4. Duration: When do we review and re-approve

From its own definition more than duration it appears to be an expiration date, or review date. Probably should be good adding both frequency and deadline.

From its own definition more than duration it appears to be an expiration date, or review date. Probably should be good adding both frequency and deadline.
Author
Contributor

Thanks! Adding both frequency and expiration.

Thanks! Adding both frequency and expiration.
fr33domlover marked this conversation as resolved
@ -15,0 +51,4 @@
(i.e. a discussion and not just collecting feedback and advice)
would produce a creative outcome
- See below instructions for each process!
6. Pick issue/MR label:

issue/PR typo?

issue/PR typo?
fr33domlover marked this conversation as resolved
fr33domlover changed title from (削除) WIP: Document decision-making process (削除ここまで) to Document decision-making process 2023年02月21日 08:00:34 +01:00
fr33domlover changed title from (削除) Document decision-making process (削除ここまで) to WIP: Document decision-making process 2023年02月21日 09:00:38 +01:00
fr33domlover changed title from (削除) WIP: Document decision-making process (削除ここまで) to Document decision-making process 2023年02月23日 22:58:15 +01:00
Ghost approved these changes 2023年02月23日 23:46:28 +01:00
Ghost left a comment

Amazing work 👍

Amazing work 👍
First-time contributor
Copy link

Hunting down and trying to remain abreast of the ever evolving and continuous flurry of merge requests is more than I'm capable of dedicating time time towards, regardless of how I or others might otherwise feel about whatever it's is that is happening in what I'm going to call a vacuum here.

Therefore, I will again call for a process whereby what you're "Proposing" is sufficiently and transparently vetted and discussed, and available for review and comment, BEFORE commits are made for merge requests affecting Governance matters that may not be agreeable to the community that is heavily taxed, impacted, and distracted from their other prorities just to try and follow slong with whatever you're attempting to enact.

suffice it to say, unless you cease from this methodology, I and many others will dissent.

The right way to do this is to publish in an accessible medium where others can participate in the process of development, or find that you're efforts to envy policy via fiat by virtue of merges categorically rejected - and we will reject anything you try to inject into the canon that is not easily peer reviewed, discussed, and resolved, prior to ANY merges by current of the community.

Whether you are on the right track or not philosophically, you're going sboutt this the wrong way - and unless you cease with this method, it will not go well. I promise you this.

The most regrettable thing, is that I'm an enthusiastic supporter of what you're trying to achieve, likely in agreement with much/most of what you propose, but you're going about this all wrong.

Hunting down and trying to remain abreast of the ever evolving and continuous flurry of merge requests is more than I'm capable of dedicating time time towards, regardless of how I or others might otherwise feel about whatever it's is that is happening in what I'm going to call a vacuum here. Therefore, I will again call for a process whereby what you're ***"Proposing"*** is sufficiently and transparently vetted and discussed, and available for review and comment, **BEFORE** commits are made for merge requests affecting Governance matters that may not be agreeable to the community that is heavily taxed, impacted, and distracted from their other prorities just to try and follow slong with whatever you're attempting to enact. suffice it to say, unless you cease from this methodology, I and many others will dissent. The right way to do this is to publish in an accessible medium where others can participate in the process of development, or find that you're efforts to envy policy via fiat by virtue of merges categorically rejected - and we will reject anything you try to **inject** into the canon that is not easily peer reviewed, discussed, and resolved, prior to ANY merges by current of the community. Whether you are on the right track or not philosophically, you're going sboutt this the wrong way - and unless you cease with this method, it will not go well. I promise you this. The most regrettable thing, is that I'm an enthusiastic supporter of what you're trying to achieve, likely in agreement with much/most of what you propose, but you're going about this all wrong.
Contributor
Copy link

I side with @tallship here.

I have a life outside of Forgejo (yes, really!) and have a hard time with following up with everything. This PR was created three weeks ago and I have only learned about it once it was merged. Too late for remarks.

There's this anxiety now, that processes and understandings were agreed upon and I am not aware of them and might tapping into pitfalls I have no idea about. That's not a healthy relationship to an organisation I would love to contribute to.

I side with @tallship here. I have a life outside of Forgejo (yes, really!) and have a hard time with following up with everything. This PR was created three weeks ago and I have only learned about it once it was merged. Too late for remarks. There's this anxiety now, that processes and understandings were agreed upon and I am not aware of them and might tapping into pitfalls I have no idea about. That's not a healthy relationship to an organisation I would love to contribute to.
Contributor
Copy link

I agree with both @tallship and @Ryuno-Ki, and even @dachary because the proposal as a whole is very good.

My main concern is that I understand this proposal to be self-contained, meaning that each of its parts is subject to the methodology itself to be approved (recursive if you prefer). So, for example, how are we to trust that everyone who might care or be affected by this decision is invited and included in a sense that gives legitimacy to the approval? You have communicated that the draft is ready for review, but where is the open and inclusive decision question posed? In the description you only talk about an edit to the existing documents, and in the chat you only say "at last the PR decision making guide is ready for review yay", which in my view is not an adequate invitation to participate in perhaps the most important meta-decision of the whole initiative.

I have made the same mistake before, so maybe first we need to decide what is the right way to make a call considered legitimate enough for good participation and involvement.

Same with the recommended waiting time for feedback, the idea is to wait only 2 weeks?
And concerns probably follow, for each person, point by point, paragraph by paragraph,... what is the rule to apply for this decision?

Maybe this guideline should be taken as it is, without the categorisation of global agreement, but to be implemented by experimenting how we go with its application. Otherwise, we should see the proposal as a fast track, where most of us will have to rely on you as the expert in decision making, but who does not apply the method itself to his major decision proposal.

I agree with both @tallship and @Ryuno-Ki, and even @dachary because the proposal as a whole is very good. My main concern is that I understand this proposal to be self-contained, meaning that each of its parts is subject to the methodology itself to be approved (recursive if you prefer). So, for example, how are we to trust that *everyone who might care or be affected by this decision is invited and included* in a sense that gives legitimacy to the approval? You have communicated that the draft is ready for review, but where is the [*open and inclusive decision question posed*](https://codeberg.org/forgejo/meta/src/commit/b98be6c7b6e40d0a1e79aa79fa3be17e89923c24/DECISION-MAKING.md?display=source#L54)? In the description you only talk about an edit to the existing documents, and in the chat you only say ["at last the PR decision making guide is ready for review yay"](https://matrix.to/#/!qjPHwFPdxhpLkXMkyP:matrix.org/$Gi1w9E1k5zEjteyISEyc0mhW0X9SFH50e2Us2fDV1Is?via=matrix.org&via=envs.net&via=tchncs.de), which in my view is not an adequate invitation to participate in perhaps the most important meta-decision of the whole initiative. I have made the same mistake before, so maybe **first** we need to **decide** what is the right way to make a call considered legitimate enough for good participation and involvement. Same with the [recommended waiting time for feedback](https://codeberg.org/forgejo/meta/src/commit/b98be6c7b6e40d0a1e79aa79fa3be17e89923c24/DECISION-MAKING.md?display=source#L64), the idea is to wait only 2 weeks? And concerns probably follow, for each person, point by point, paragraph by paragraph,... what is the rule to apply for this decision? Maybe this guideline should be taken as it is, without the categorisation of global agreement, but to be implemented by experimenting how we go with its application. Otherwise, we should see the proposal as a fast track, where most of us will have to rely on you as the expert in decision making, but who does not apply the method itself to his major decision proposal.
Member
Copy link

I will again call for a process whereby what you're "Proposing" is sufficiently and transparently vetted and discussed, and available for review and comment, BEFORE commits are made for merge requests

So, do you think that, in general, PRs should only be implementing previously discussed and approved issues ?

Because we didn't hear from you in #124, #131 and #132 on this matter, those were focused on source code indeed, but I think it's also relevant here.

I [...] have a hard time with following up with everything. This PR was created three weeks ago and I have only learned about it once it was merged.

Try using the watch feature.
It isn't merged, though.

> I will again call for a process whereby what you're "Proposing" is sufficiently and transparently vetted and discussed, and available for review and comment, BEFORE commits are made for merge requests So, do you think that, in general, PRs should only be implementing previously discussed and approved issues ? Because we didn't hear from you in #124, #131 and #132 on this matter, those were focused on source code indeed, but I think it's also relevant here. > I [...] have a hard time with following up with everything. This PR was created three weeks ago and I have only learned about it once it was merged. Try using the *[watch](/forgejo/meta/watchers)* feature. It isn't merged, though.
Contributor
Copy link

Oh, I'm watching. My time on Codeberg is limited because I have to care for family members.

Oh, I'm watching. My time on Codeberg is limited because I have to care for family members.
Author
Contributor
Copy link

@tallship, I hear your concern about governance changes being "landed" by a single person without the reasonable possibility of review.

@Ryuno-Ki, I hear your concern for your limited time and therefore the impact of a long decision-making guide being written, which would take a lot of time to read. And the anxiety about possible agreements being made without you being aware.

Here's a clarification about this PR and about governance stuff in general, which I'll also edit into the PR's description.

  • The current (merged) version of the decision-making guide is a simplified form of a method called Convergent Facilitation, with bits from another methodology called Sociocracy
  • That guide has been merged for a while, so that people can try it and we can learn and evolve the process if/as needed
  • This PR just adds a full detailed version of the process, so that even if I disappear, there's a good basis to work with

Do you trust me enough to give this guide a chance?

If you don't have time to review the thing, I totally get it, I know it's long and I know it talks about stuff that might sound unfamiliar.

This guide doesn't have operational impacts, it doesn't make any operational agreements.

I can ask you "are you okay with us using Convergent Facilitation" but in order for you to answer that, you'd need to learn that process, read materials and practice, to able to tell whether using that process makes sense. I don't believe it's realistic to have everyone learn all the methodologies, just for us to be able to decide how we decide stuff.

Instead, I prepared a (hopefully) friendly guide specifically adapted for Forgejo, that we can try here in Forgejo and then we can see how it feels. And if the feedback says it's not working for us, then we can improve it. Or throw it away.

Perhaps I haven't done enough to gather consent for entrustment (i.e. for people trusting me to bring these tools in a safe manner into the project). This is precious feedback for me, for the future. But let's figure out the present first.

Questions

  1. I edited the PR's description - can you read it? And after reading, are you opposed this PR and to the way it's presented?

  2. If opposed - do you have an idea/proposal/request for how to proceed here?

@tallship, I hear your concern about governance changes being "landed" by a single person without the reasonable possibility of review. @Ryuno-Ki, I hear your concern for your limited time and therefore the impact of a long decision-making guide being written, which would take a lot of time to read. And the anxiety about possible agreements being made without you being aware. Here's a clarification about this PR and about governance stuff in general, which I'll also edit into the PR's description. - The current (merged) version of the decision-making guide is a simplified form of a method called Convergent Facilitation, with bits from another methodology called Sociocracy - That guide has been merged for a while, so that people can try it and we can learn and evolve the process if/as needed - This PR just adds a full detailed version of the process, so that even if I disappear, there's a good basis to work with Do you trust me enough to give this guide a chance? If you don't have time to review the thing, I totally get it, I know it's long and I know it talks about stuff that might sound unfamiliar. This guide doesn't have operational impacts, it doesn't make any operational agreements. I can ask you "are you okay with us using Convergent Facilitation" but in order for you to answer that, you'd need to learn that process, read materials and practice, to able to tell whether using that process makes sense. I don't believe it's realistic to have everyone learn all the methodologies, just for us to be able to decide how we decide stuff. Instead, I prepared a (hopefully) friendly guide *specifically adapted for Forgejo*, that we can *try here in Forgejo* and then we can see how it feels. And if the feedback says it's not working for us, then we can improve it. Or throw it away. Perhaps I haven't done enough to gather consent for entrustment (i.e. for people trusting me to bring these tools in a safe manner into the project). This is precious feedback for me, for the future. But let's figure out the present first. # Questions 1. I edited the PR's description - can you read it? And after reading, are you opposed this PR and to the way it's presented? 2. If opposed - do you have an idea/proposal/request for how to proceed here?
Contributor
Copy link

The following is my own opinion. If you feel to talk on one-on-one I'm happy to do so as well.

First of all: It's not my intention to trigger you emotionally. I'm aware that you are investing a lot of time and energy into this matter and act in good faith. Thank you for that.

My anxiety is - as mentioned - to run into pitfalls.

If you write

This guide doesn't have operational impacts, it doesn't make any operational agreements.

then my stress is relieved for a bit.

we can see how it feels. And if the feedback says it's not working for us, then we can improve it. Or throw it away.

makes it sound like kind of an experiment.
As in, it is okay if this turns out to be not working. It's not set in stone.

Do you have a specific form you would like to receive feedback?

Perhaps I haven't done enough to gather consent for entrustment (i.e. for people trusting me to bring these tools in a safe manner into the project).

If I were to organise feedback, I'd go through the TEAMS document and contact those people I haven't seen a reaction from on a proposal. To some degree I already noticed this on the chat.

I'm not opposed to this concrete PR. I'm worried about the velocity in which we add new documents to our repos. Especially if they appear to be important of some kind.

The following is my own opinion. If you feel to talk on one-on-one I'm happy to do so as well. First of all: It's not my intention to trigger you emotionally. I'm aware that you are investing a lot of time and energy into this matter and act in good faith. Thank you for that. My anxiety is - as mentioned - to run into pitfalls. If you write > This guide doesn't have operational impacts, it doesn't make any operational agreements. then my stress is relieved for a bit. > we can see how it feels. And if the feedback says it's not working for us, then we can improve it. Or throw it away. makes it sound like kind of an experiment. As in, it is okay if this turns out to be not working. It's not set in stone. Do you have a specific form you would like to receive feedback? > Perhaps I haven't done enough to gather consent for entrustment (i.e. for people trusting me to bring these tools in a safe manner into the project). If I were to organise feedback, I'd go through the TEAMS document and contact those people I haven't seen a reaction from on a proposal. To some degree I already noticed this on the chat. I'm not opposed to this concrete PR. I'm worried about the velocity in which we add new documents to our repos. Especially if they appear to be important of some kind.
Author
Contributor
Copy link
  • I added an intro paragraph to clarify the guide is a recommendation, not a rule you "must" follow
  • I updated the table in AGREEMENTS.md to clarify this as well

I'm now going to merge this PR. We'll gather ongoing feedback as/if/when people use the guide.

From now on I'll more clearly gather approval/entrustment before I start working on such a detailed document, to make sure there's a sense of trust and togetherness.

- I added an intro paragraph to clarify the guide is a recommendation, not a rule you "must" follow - I updated the table in AGREEMENTS.md to clarify this as well I'm now going to merge this PR. We'll gather ongoing feedback as/if/when people use the guide. From now on I'll more clearly gather approval/entrustment before I start working on such a detailed document, to make sure there's a sense of trust and togetherness.
Commenting is not possible because the repository is archived.
No reviewers
Labels
Clear labels
[Decision] Building proposal(s)
We're in a decision-making process, buiding one or more proposals to address the shared aim based on the criteria
[Decision] Gathering criteria
We're in a decision-making process, gathering criteria, considerations and needs
[Decision] Integrating concerns
We're in a decision-making process, working with a proposal, trying to integrate concerns and create modifications/support such that the proposal works for everyone
Accessibility
Relates to Accessibility (a11y) of product, project and process.
Agreement proposal
Forgejo agreement proposal, following a discussion
Communication
Relates to all channels, social media, website, blog posts.
Election
Process of appointing a person into a role or team (if choosing people just for a specific one-time task, use the Entrustment label)
Entrustment
Process of choosing/approving specific people to do a critical/high-impact one-time task (if choosing people for an ongoing role/team, use the Election label)
Governance
Relates to processes, procedures and decision-making.
Meeting
An upcoming team meeting
User research - Accessibility
Requires input about accessibility features, likely involves user testing.
User research - Blocked
Do not pick as-is! We are happy if you can help, but please coordinate with ongoing redesign in this area.
User research - Community
Community features, such as discovering other people's work or otherwise feeling welcome on a Forgejo instance.
User research - Config (instance)
Instance-wide configuration, authentication and other admin-only needs.
User research - Errors
How to deal with errors in the application and write helpful error messages.
User research - Filters
How filter and search is being worked with.
User research - Future backlog
The issue might be inspiring for future design work.
User research - Git workflow
AGit, fork-based and new Git workflow, PR creation etc
User research - Labels
Active research about Labels
User research - Moderation
Moderation Featuers for Admins are undergoing active User Research
User research - Needs input
Use this label to let the User Research team know their input is requested.
User research - Notifications/Dashboard
Research on how users should know what to do next.
User research - Rendering
Text rendering, markup languages etc
User research - Repo creation
Active research about the New Repo dialog.
User research - Repo units
The repo sections, disabling them and the "Add more" button.
User research - Security
User research - Settings (in-app)
How to structure in-app settings in the future?
Milestone
Clear milestone
No items
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
6 participants Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
forgejo/meta!148
Reference in a new issue
forgejo/meta
No description provided.
Delete branch "fr33domlover/forgejo-meta:dm-guide"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?