Archived
15
23
Fork
You've already forked meta
6

Feedback on Decision-Making process #168

Open
opened 2023年02月23日 06:47:30 +01:00 by circlebuilder · 2 comments
Contributor
Copy link

@fr33domlover in Forge Federation chat asked feedback on Decision Making process:

I'd like to hear your thoughts about a fundamental question about decision-making in Forgejo!

Assume a process where anyone can (1) open an issue about a decision, (2) collect advice from the community via issue coments, and (3) take the advice into serious consideration, make a final decision on behalf of the community (4) open any follow-up issues e.g. implementing the decision

This allows efficient smooth collaboration, because for whole-project-scope decisions, we don't have to wait to get active consensus from the whole organization/community/universe :P but this process requires personal responsibility to care for the needs of the project, which means we trust each other to make decisions with care

Question: Do we want to allow only Forgejo Organization members to use this process, i.e. to collect advice and make a decision? Or do we want to allow anyone to do that?

  • If we allow only the Org members, there's more trust that decisions are made with care, but it creates a feeling of hierarchy where there's a selected small group that has more power than other people, and there's a tech challenge because anyone can close an issue they opened and Idk if Gitea/Forgejo has a setting to change that
  • If we allow anyone to use that process, there's a chance that "random people from out there" make a decision without responsible gathering of advice and/or without seriously considering the advice, which might sound scary, but (1) it can happen to us too (2) it allows a welcoming, smooth and supportive environment for people to get involved or increase their involvement and feel empowered and trusted; it can help create trust in the community (3) we can watch the issues board - which we probably do anyway - for closed issues with surprising or controversial decisions and processes - and talk to those people as needed and help them learn the decision process if they did something like deciding without taking advice etc. etc. (4) it can be an experiment for a month or few months and then we see how it goes (5) The decision-making guide can have a paragraph about self-selection, i.e. for people in the community to self-assess whether they're capable of doing the advice process, and ask for support/mentorship if they need

Thoughts about which path to take? ❤️

@fr33domlover in [Forge Federation chat](https://matrix.to/#/!qjPHwFPdxhpLkXMkyP:matrix.org/$h0mYjXQ9xaTxhhnuG6Eco8Xne0F_VrLDIY-fkp9CFdc?via=matrix.org&via=envs.net&via=tchncs.de) asked feedback on Decision Making process: >I'd like to hear your thoughts about a fundamental question about decision-making in Forgejo! > > Assume a process where anyone can (1) open an issue about a decision, (2) collect advice from the community via issue coments, and (3) take the advice into serious consideration, make a final decision on behalf of the community (4) open any follow-up issues e.g. implementing the decision > > This allows efficient smooth collaboration, because for whole-project-scope decisions, we don't have to wait to get active consensus from the whole organization/community/universe :P but this process requires **personal responsibility** to care for the needs of the project, which means we **trust** each other to make decisions with care > > Question: Do we want to allow only Forgejo Organization members to use this process, i.e. to collect advice and make a decision? Or do we want to allow _anyone_ to do that? > > - If we allow only the Org members, there's more trust that decisions are made with care, **but** it creates a feeling of hierarchy where there's a selected small group that has more power than other people, **and** there's a tech challenge because anyone can close an issue they opened and Idk if Gitea/Forgejo has a setting to change that > - If we allow _anyone_ to use that process, there's a chance that "random people from out there" make a decision without responsible gathering of advice and/or without seriously considering the advice, which might sound scary, **but** (1) it can happen to us too (2) it allows a welcoming, smooth and supportive environment for people to get involved or increase their involvement and feel empowered and trusted; it can help create trust in the community (3) we can watch the issues board - which we probably do anyway - for closed issues with surprising or controversial decisions and processes - and talk to those people as needed and help them learn the decision process if they did something like deciding without taking advice etc. etc. (4) it can be an experiment for a month or few months and then we see how it goes (5) The decision-making guide can have a paragraph about self-selection, i.e. for people in the community to self-assess whether they're capable of doing the advice process, and ask for support/mentorship if they need > > Thoughts about which path to take? ❤️
Author
Contributor
Copy link

I created this issue to record my feedback, since I am unavailable next week:

Thinking of a combination of 1) and 2) whereby..

  • Anyone can raise issues.
    • Either the person raising or people from a team mark the issue as a Decision (with a label).
  • Once a Decision is proposed a process starts.
    • There must be someone responsible for preparing/elaborating the Decision issue. This either includes the person who raised the issue, or this person should find one or more people to assign this to.
    • This implies a certain commitment / obligation. If the person or other people are interested in the subject they must do some work to carry things further.
    • If no one picks up the glove, the Decision issue is 'just-an-idea' and sits on the backlog, until a team member might groom it by asking "Are you interested to take this further?". If not, it is closed.
  • Furthering the issue may involve filling in a template:
    • Background and description (clarify the need and nature of the decision)
    • Impact (what are the consequences and changes to the project?)
    • Who is affected? (which persons/roles will be impacted most?)
    • Work items (bullet list with things-to-do if the decision is positive and/or negative)
    • Who can vote? (varies based nature of decision + impact + people affected)
  • The template is turned into a comprehensive doc by following the Advice process, collect feedback.
  • Once ready actual decision can be made:
    • "Ready for decision" consent is sought by team members.
    • Designated voters vote.
    • Follow-up actions (outlined in Work Items) are set in motion.
    • Decision doc is archived / remains in decision log.
I created this issue to record [my feedback](https://matrix.to/#/!qjPHwFPdxhpLkXMkyP:matrix.org/$ZPJhfRz2UswQiEBrooi62WA6PXRAC5BUZ6Q0GahXCxA?via=matrix.org&via=envs.net&via=tchncs.de), since I am unavailable next week: > Thinking of a combination of 1) and 2) whereby.. > > - Anyone can raise issues. > - Either the person raising or people from a team mark the issue as a Decision (with a label). > - Once a Decision is proposed a process starts. > - There must be someone responsible for preparing/elaborating the Decision issue. This either includes the person who raised the issue, or this person should find one or more people to assign this to. > - This implies a certain commitment / obligation. If the person or other people are interested in the subject they must do some work to carry things further. > - If no one picks up the glove, the Decision issue is 'just-an-idea' and sits on the backlog, until a team member might groom it by asking "Are you interested to take this further?". If not, it is closed. > - Furthering the issue may involve filling in a template: > - Background and description (clarify the need and nature of the decision) > - Impact (what are the consequences and changes to the project?) > - Who is affected? (which persons/roles will be impacted most?) > - Work items (bullet list with things-to-do if the decision is positive and/or negative) > - Who can vote? (varies based nature of decision + impact + people affected) > - The template is turned into a comprehensive doc by following the Advice process, collect feedback. > - Once ready actual decision can be made: > - "Ready for decision" consent is sought by team members. > - Designated voters vote. > - Follow-up actions (outlined in Work Items) are set in motion. > - Decision doc is archived / remains in decision log.

Ref: here and here

Ref: [here](https://codeberg.org/forgejo/meta/issues/166) and [here](https://codeberg.org/forgejo/meta/issues/167)
Commenting is not possible because the repository is archived.
No Branch/Tag specified
readme
No results found.
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
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
forgejo/meta#168
Reference in a new issue
forgejo/meta
No description provided.
Delete branch "%!s()"

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?