Archived
15
23
Fork
You've already forked meta
6

Designing an election mechanism #186

Open
opened 2023年03月01日 14:58:27 +01:00 by fr33domlover · 4 comments
Contributor
Copy link

Situation

We don't yet have an explicit process for assigning roles to people in the project. The general decision-making process is a good basis, but it doesn't tackle all the questions and challenges related to election (e.g. who facilitates the election process; how to determine (and who determines) who's a relevant candidate for a given role, etc.)

An election process is a significant component of the project's governance, and it can be challenging (and has been challenging) to maintain trust in a globally-distributed-community all-volunteer project, especially with the high pace of governance issues and proposals being made (ironically this issue is another one).

The current roles and teams are in TEAMS.md.

Question

Who will facilitate the decision-making process, in which an initial election process will be designed?

And who will be the people to the design the election mechanism? And how many parallel proposals shall we create as a community?

Proposal

  • I (fr33domlover) will facilitate the decision-making process in which we'll create an election mechanism
  • The decision-making process will happen in an issue so everyone, the whole community, can participate in shaping the election mechanism (but proposal co-authoring can be coordinated using Matrix/Jitsi/HedgeDoc/etc.)
  • We can have as many mechanism proposals as people in the community wish, however:
    • Each proposal must be co-authored by at least 2 people (preferably at least 3 people)
    • I (fr33domlover) will work on (at least) one of these proposals:
      • Probably based on an integration of our current decision-making process and the Sociocracy election process
      • And feedback and learnings from our current situation
      • Together with anyone who wishes to work together on such a proposal (same as above applies here too: Must be at least 2 people, preferably at least 3)
      • Using a Jitsi meeting to talk while working, either during a governance meeting or a separate Jitsi meeting

So if you'll want to participate in the proposal-writing step (when we get to that step), you can:

  • Either find 1-2 more people and write a proposal together
  • And/or join an existing proposal team (either the one I'll be in, or any other team that forms)

The process of deciding on the election mechanism will be our general decision-making process :-) (I hope that's not too confusing)

tl;dr I'm proposing to: (1) facilitate (i.e. guide/lead) the community process of designing an election mechanism (2) to co-author one of the mechanism proposals, via a Jitsi meeting anyone can join

Request

Is the above clear? If you have any clarification question to ask, comment and ask.

If it's clear, does it make sense? Are you comfortable with what I'm proposing?

  • If comfortable and approving, react with thumb-up
  • If uncomfortable, if having any concern, if what I'm proposing doesn't seem safe enough or not serving the project and community, please comment about the concern
# Situation We don't yet have an explicit process for assigning roles to people in the project. The general decision-making process is a good basis, but it doesn't tackle all the questions and challenges related to election (e.g. who facilitates the election process; how to determine (and who determines) who's a relevant candidate for a given role, etc.) An election process is a significant component of the project's governance, and it can be challenging (and has been challenging) to maintain trust in a globally-distributed-community all-volunteer project, especially with the high pace of governance issues and proposals being made (ironically this issue is another one). The current roles and teams are in [TEAMS.md](https://codeberg.org/forgejo/meta/src/branch/readme/TEAMS.md). # Question Who will facilitate the decision-making process, in which an initial election process will be designed? And who will be the people to the design the election mechanism? And how many parallel proposals shall we create as a community? # Proposal - I (fr33domlover) will facilitate the decision-making process in which we'll create an election mechanism - The decision-making process will happen in an **issue** so everyone, the whole community, can participate in shaping the election mechanism (but proposal co-authoring can be coordinated using Matrix/Jitsi/HedgeDoc/etc.) - We can have as many mechanism proposals as people in the community wish, however: - Each proposal must be co-authored by at least 2 people (preferably at least 3 people) - I (fr33domlover) will work on (at least) one of these proposals: - Probably based on an integration of our current decision-making process and the Sociocracy election process - And feedback and learnings from our current situation - **Together with anyone who wishes** to work together on such a proposal (same as above applies here too: Must be at least 2 people, preferably at least 3) - Using a Jitsi meeting to talk while working, either during a governance meeting or a separate Jitsi meeting So if you'll want to participate in the proposal-writing step (when we get to that step), you can: - Either find 1-2 more people and write a proposal together - And/or join an existing proposal team (either the one I'll be in, or any other team that forms) The process of deciding on the election mechanism will be our general decision-making process :-) (I hope that's not too confusing) **tl;dr I'm proposing to: (1) facilitate (i.e. guide/lead) the community process of designing an election mechanism (2) to co-author one of the mechanism proposals, via a Jitsi meeting anyone can join** # Request Is the above clear? If you have any clarification question to ask, comment and ask. If it's clear, does it make sense? Are you comfortable with what I'm proposing? - If comfortable and approving, **react with thumb-up** - If uncomfortable, if having any concern, if what I'm proposing doesn't seem safe enough or not serving the project and community, **please comment** about the concern
fr33domlover changed title from (削除) Who will design an election process (削除ここまで) to Designing an election mechanism 2023年03月01日 15:03:47 +01:00
Member
Copy link

Why would we need that in a do-ocracy ?

Why would we need that in a do-ocracy ?
Author
Contributor
Copy link

@KaKi87, look at TEAMS.md. Can you see the value of having the teams listed there? e.g.:

  • Do we give anyone who asks the access to passwords, cryptographic keys for signing release, etc.? If not, who are the people we entrust to hold these sensitive resources? How do we select these people?

  • While we have fun coding stuff, who does the task making a monthly release? It doesn't make sense for 50 people to gather on Matrix and do it somehow together, but 3 is enough and effective, and allows us to trust that releases happen because those 3 people are on it - how do we choose them? How often do we re-elect this release team?

  • When we have a conflict between team members and we need help with mediation, who do we ask for help? Who in the team can mediate a conflict, who do we trust to do so without taking one side and neglecting the other? How do we choose these people together?

And so on.

Also, without roles,

  • People do what's fun and interesting, and important-but-not-fun tasks can be forgotten
  • Everyone has to do everything (that has impacts on others) together which is ineffective and impractical
  • It's not clear who's an expert in what, and how to distribute tasks and ask for support based on that

@KaKi87, is this helpful in clarifying the need for roles and teams?

@KaKi87, look at [TEAMS.md](https://codeberg.org/forgejo/meta/src/branch/readme/TEAMS.md). Can you see the value of having the teams listed there? e.g.: - Do we give *anyone who asks* the access to passwords, cryptographic keys for signing release, etc.? If not, who are the people we entrust to hold these sensitive resources? How do we select these people? - While we have fun coding stuff, who does the task making a monthly release? It doesn't make sense for 50 people to gather on Matrix and do it somehow together, but 3 is enough and effective, and allows us to trust that releases happen because those 3 people are on it - how do we choose them? How often do we re-elect this release team? - When we have a conflict between team members and we need help with mediation, who do we ask for help? Who in the team can mediate a conflict, who do we trust to do so without taking one side and neglecting the other? How do we choose these people together? And so on. Also, without roles, - People do what's fun and interesting, and important-but-not-fun tasks can be forgotten - Everyone has to do everything (that has impacts on others) together which is ineffective and impractical - It's not clear who's an expert in what, and how to distribute tasks and ask for support based on that @KaKi87, is this helpful in clarifying the need for roles and teams?
Member
Copy link

Yes.

Yes.
Contributor
Copy link

Is very ironic and sad that the single thumb up to your proposal in this community have been mine @fr33domlover. I really appreciate your effort to give it to Forgejo.

Is very ironic and sad that the single thumb up to your proposal in this community have been mine @fr33domlover. I really appreciate your effort to give it to Forgejo.
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
3 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#186
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?