Archived
15
23
Fork
You've already forked meta
6

Governance bootstrap #19

Open
opened 2022年11月07日 13:09:05 +01:00 by Ghost · 67 comments

Codeberg is trusted to hold the domains and trademark, which means that they are the ultimate authority on the Gitea fork. They are a non-profit dedicated to Free Software with a democratic structure and built trust over a years.

The people who work on the Gitea fork do not need a governance: they can rely on the moderation team of Codeberg in case an account is doing something bad like spamming. But they also need to make decisions and trust each other with secrets like the key used to sign releases.

And that calls for what could be called, for lack of a better word, a "Sub Governance". This is the reason why a Code of Conduct is adopted and people appointed for moderation, for instance. In the bootstrap phase, while this "Sub Governance" is put in place, people hold positions for short period of time (a few months), just enough for a decision process to be agreed upon. And after that, they will be appointed based on this decision process instead of semi-randomly.

Codeberg is trusted to hold the domains and trademark, which means that they are the ultimate authority on the Gitea fork. They are a non-profit dedicated to Free Software with a democratic structure and built trust over a years. The people who work on the Gitea fork do not need a governance: they can rely on the moderation team of Codeberg in case an account is doing something bad like spamming. But they also need to make decisions and trust each other with secrets like the key used to sign releases. And that calls for what could be called, for lack of a better word, a "Sub Governance". This is the reason why [a Code of Conduct is adopted](https://codeberg.org/codename/meta/issues/13) and people appointed for moderation, for instance. In the bootstrap phase, while this "Sub Governance" is put in place, people hold positions for short period of time (a few months), just enough for a decision process to be agreed upon. And after that, they will be appointed based on this decision process instead of semi-randomly.

@onepict would you be interested in establishing this "Sub Governance"? I would really enjoy working with you on that because it is low pressure: whatever is done must be within the boundaries of Codeberg governance anyways.

@onepict would you be interested in establishing this "Sub Governance"? I would really enjoy working with you on that because it is low pressure: whatever is done must be within the boundaries of Codeberg governance anyways.

Yes I am happy to help with this.

Yes I am happy to help with this.

I propose we let this here for a few days so people get a chance to comment on the general idea. If there are no objections, we can start moving forward.

I propose we let this here for a few days so people get a chance to comment on the general idea. If there are no objections, we can start moving forward.
Contributor
Copy link

Can we have this formalised (perhaps similar to the CoC issue), that people vow to step down once a proper governance was elected? I trust onepict would do so if asked, but I want to avoid another scenery like the one that led to Gitea Ltd.

Can we have this formalised (perhaps similar to the CoC issue), that people vow to step down once a proper governance was elected? I trust onepict would do so if asked, but I want to avoid another scenery like the one that led to Gitea Ltd.

... I want to avoid another scenery like the one that led to Gitea Ltd.

If something bad happens Codeberg has control and can step, reason why I'm not overly worried.

> ... I want to avoid another scenery like the one that led to Gitea Ltd. If something bad happens Codeberg has control and can step, reason why I'm not overly worried.

@fr33domlover: you've done a wonderful job with the name picking process 👍️ This sets an example of what I would like to be part of when defining the governance. Do you feel like leading this?

@fr33domlover: you've done a wonderful job with the name picking process 👍️ This sets an example of what I would like to be part of when defining the governance. Do you feel like leading this?

FYI to avoid spamming the main chatroom, another one was temporarily created to discuss decision making.

FYI to avoid spamming the main chatroom, [another one was temporarily created](https://matrix.to/#/#codename-decision-making:matrix.org) to discuss decision making.

A videoconference will be held Thursday, Nov 24, 17:00 - 18:30 UTC.

A videoconference [will be held](https://matrix.to/#/!ivhsRdiJkcDjdwTZSF:towards.vision/$nalbHXoM-TXAxnrhww3ArZmb26ajRTWQ__kb5hF2XUo?via=exozy.me&via=matrix.org&via=towards.vision) Thursday, Nov 24, 17:00 - 18:30 UTC.

Actions

  • @dachary : set a framadate for the next meeting, 2 weeks from now
  • @fr33domlover : process values that matter to people with regard to Forgejo, as written above and discussed in the meeting
  • @onepict : look at the tagline discussion, ping fr33 to look at it together

Recording (audio only): https://codeberg.org/forgejo/meta/src/branch/readme/2022-11-24-videoconference-governance.mp3

Edit by Ryuno-Ki: Added checkboxes ☑️
Edit by @dachary: the tagline discussion is concluded & copy pasted the pad for the record.

Decision making meeting 2022年11月24日

Participants: esther, loic, felipe, gusted, fnetx, fr33

Question: what are the points that are important for you with regard to governance?

  • Don't create an elite of few old team members who don't want/support new members

Loic

  • Document
    • Goals of the project
    • How decisions are made
  • Moderation procedure https://framagit.org/chatons/CHATONS/-/blob/master/docs/Mod%C3%A9ration%20forum/Process%20de%20mod%C3%A9ration.md
  • Core values of people involved in the project and the ability to fork the project
  • https://hackerspace.design/ related to doocracy
  • Decision making system should be explicit (not explicit leads to https://www.jofreeman.com/joreen/tyranny.htm)
  • Transparency
  • Democracy
  • Diversity
  • Accessibility
  • Simple - i.e. a newcomer should be able to grasp the governance within minutes, it should not be too involved
  • Code of Conduct and well being / moderation teams
  • Meaningful elections (people explain why they want to be elected and what they plan to do)
  • DoOcracy - i.e. the people in power are the people doing work
  • User Centric - i.e. new features are motivated by user needs rather than a single individual desire
  • People who have power (because elected or because they have access to DNS or other exclusive resources) are bound to share it and this obligation is exercized on a regular basis
  • If people are elected by the community they accept responsibilities, such as focusing on the roadmap instead of their personal desires (which is fine for non elected people)

???

Decision making document

Organizational systems

  • Info flow
  • Resource flow
  • Decision making
  • Feedback flow
  • Conflict engagement
  • Personal care/support

System to start with:

  • Manifesto:
    • Vision and purpose
    • Values and principles
  • Agreements and policies
    • Roles and accountabilities
    • Onboarding (good first issues, e.g. like in OpenStack)
    • Who mentors new people on which parts of the project
Actions * [x] @dachary : set a framadate for the next meeting, 2 weeks from now * [ ] @fr33domlover : process values that matter to people with regard to Forgejo, as written above and discussed in the meeting * [x] @onepict : look at the tagline discussion, ping fr33 to look at it together Recording (audio only): https://codeberg.org/forgejo/meta/src/branch/readme/2022-11-24-videoconference-governance.mp3 Edit by Ryuno-Ki: Added checkboxes ☑️ Edit by @dachary: the tagline discussion is concluded & copy pasted the pad for the record. --- # Decision making meeting 2022年11月24日 Participants: esther, loic, felipe, gusted, fnetx, fr33 Question: what are the points that are important for you with regard to governance? - Don't create an elite of few old team members who don't want/support new members ## Loic * Document * Goals of the project * How decisions are made * Moderation procedure https://framagit.org/chatons/CHATONS/-/blob/master/docs/Mod%C3%A9ration%20forum/Process%20de%20mod%C3%A9ration.md * Core values of people involved in the project and the ability to fork the project * https://hackerspace.design/ related to doocracy * Decision making system should be explicit (not explicit leads to https://www.jofreeman.com/joreen/tyranny.htm) * Transparency * Democracy * Diversity * Accessibility * Simple - i.e. a newcomer should be able to grasp the governance within minutes, it should not be too involved * Code of Conduct and well being / moderation teams * Meaningful elections (people explain why they want to be elected and what they plan to do) * DoOcracy - i.e. the people in power are the people doing work * User Centric - i.e. new features are motivated by user needs rather than a single individual desire * People who have power (because elected or because they have access to DNS or other exclusive resources) are bound to share it and this obligation is exercized on a regular basis * If people are elected by the community they accept responsibilities, such as focusing on the roadmap instead of their personal desires (which is fine for non elected people) ## ??? Decision making document Organizational systems - Info flow - Resource flow - Decision making - Feedback flow - Conflict engagement - Personal care/support System to start with: - Manifesto: - Vision and purpose - Values and principles - Agreements and policies - Roles and accountabilities - Onboarding (good first issues, e.g. like in OpenStack) - Who mentors new people on which parts of the project

Another videoconference will happen in two weeks time to continue the work on the Forgejo governance. Kindly pick a date/time that has your preference. Everyone is welcome to attend. It will be recorded (audio only).

Date poll https://framadate.org/oi3JPI3Du3G89Lm3
Admin of the poll https://framadate.org/oi3JPI3Du3G89Lm3
Announcement in the Forgejo chatroom

Another videoconference will happen in two weeks time to continue the work on the Forgejo governance. Kindly [pick a date/time that has your preference](https://framadate.org/oi3JPI3Du3G89Lm3). Everyone is welcome to attend. It will be recorded (audio only). Date poll https://framadate.org/oi3JPI3Du3G89Lm3 Admin of the poll https://framadate.org/oi3JPI3Du3G89Lm3 Announcement [in the Forgejo chatroom](https://matrix.to/#/!qjPHwFPdxhpLkXMkyP:matrix.org/$SS1Py1jJmrTWBQr7gkdYVNotKWo89_mzq2OzefvOtgI?via=matrix.org&via=exozy.me&via=tchncs.de)

Announced in the chatroom:

Another videoconference will happen December 10th, 2022 5pm UTC to continue the work on the Forgejo governance. Everyone is invited to participate and get updates by following the dedicated Forgejo issue.

And set the due date of this issue accordingly.

[Announced in the chatroom](https://matrix.to/#/!qjPHwFPdxhpLkXMkyP:matrix.org/$VbSc3X4XNfBeCv0nsvwAyxns4FDLhn4A3HxyRqIApFk?via=matrix.org&via=exozy.me&via=tchncs.de): > Another videoconference will happen December 10th, 2022 5pm UTC to continue the **work on the Forgejo governance**. Everyone is invited to participate and [get updates by following the dedicated Forgejo issue](https://codeberg.org/forgejo/meta/issues/19). And set the **due date** of this issue accordingly.
Ghost added the due date 2022年12月10日 2022年11月28日 08:14:55 +01:00
Ghost changed title from (削除) Sub Governance bootstrap (削除ここまで) to Governance bootstrap 2022年11月28日 08:18:17 +01:00

Updated the title of the issue because the Sub prefix is not meaningful to anyone, it was a bad idea on my part.

Updated the title of the issue because the **Sub** prefix is not meaningful to anyone, it was a bad idea on my part.

@fr33domlover I re-assigned yourself because you were dropped from the list but I'm not sure why.

@fr33domlover I re-assigned yourself because you were dropped from the list but I'm not sure why.

Here is a pad for today's Governance meeting where everyone can add items to the agenda.

https://pad.gusted.xyz/VAIfiiqQQomLCV1yTR4yMQ#

A reminder was sent to the chatroom.

@room on behalf of fr33domlover a gentle reminder that the second Forgejo Governance meeting is schedule today 10 December 2022 5pm UTC at https://meet.jit.si/FascinatingDatesReviewReadily. Feel free to add items that matter to you to the agenda

Here is a pad for today's Governance meeting where everyone can add items to the agenda. https://pad.gusted.xyz/VAIfiiqQQomLCV1yTR4yMQ# A reminder was [sent to the chatroom](https://matrix.to/#/!qjPHwFPdxhpLkXMkyP:matrix.org/$lM6hs6ehuPlEwOlJl5RlDkrMkH96aSCkA-ewVpXpSEM?via=matrix.org&via=exozy.me&via=tchncs.de). > @room on behalf of fr33domlover a gentle reminder that the [second Forgejo Governance meeting](https://codeberg.org/forgejo/meta/issues/19#issuecomment-711201) is schedule today 10 December 2022 5pm UTC at https://meet.jit.si/FascinatingDatesReviewReadily. Feel free to add items that matter to you to [the agenda](https://pad.gusted.xyz/VAIfiiqQQomLCV1yTR4yMQ#)

The recording of the (2h) meeting:

https://codeberg.org/forgejo/meta/src/branch/readme/2022-12-10-videoconference-governance.mp3

Call for participation in the chatroom:

@room you are kindly invited to choose a date and time of your preference of the first Forgejo monthly meeting at https://framadate.org/xnUIJQSEvWHIEzaJ. It will be an opportunity to discuss governance and more.

The recording of the (2h) meeting: https://codeberg.org/forgejo/meta/src/branch/readme/2022-12-10-videoconference-governance.mp3 Call for participation [in the chatroom](https://matrix.to/#/!qjPHwFPdxhpLkXMkyP:matrix.org/$GKlshDtdCir9cehWdeUFas139qL5_CvnL7zrssWp6KI?via=matrix.org&via=exozy.me&via=tchncs.de): > @room you are kindly invited to choose a date and time of your preference of the first Forgejo monthly meeting at https://framadate.org/xnUIJQSEvWHIEzaJ. It will be an opportunity to discuss governance and more.

The list of teams was created and will be updated every month.

The [list of teams](https://codeberg.org/forgejo/meta#teams) was created and will be updated every month.
Contributor
Copy link

@dachary I'm attaching decision-making guide, please let me if you have questions an feel free to make/suggest edits; I know I sometimes write too much

Everyone, feel free to read and comment :-)

@dachary there's a missing piece at the bottom, who/where to ask for support. Perhaps have some 2-3 people listed there (including me)? Or have a Matrix room for decision-making support?

@dachary I'm attaching decision-making guide, please let me if you have questions an feel free to make/suggest edits; I know I sometimes write too much Everyone, feel free to read and comment :-) @dachary there's a missing piece at the bottom, who/where to ask for support. Perhaps have some 2-3 people listed there (including me)? Or have a Matrix room for decision-making support?
Contributor
Copy link

Actually, I already have suggested edits to that :P so commenting them here (we'll need to decide who has access to edit that file once it's in the repo...)

Another concept for the list:

  • We seek to make a decision that is:
    • Good enough for now, safe enough to try (i.e. it doesn't need to be perfect)
    • Moving us towards our shared goal
  • So we think of concerns and oppositions as gifts expressing a potential reason that the current proposal:
    • Isn't good enough for the current circumstances
    • Isn't safe enough to try
    • Hinders or endangers our progress towards the shared goal

To avoid making the concepts list too long, I'll try to shorten the existing list to make room for this new stuff ^_^

Actually, I already have suggested edits to that :P so commenting them here (we'll need to decide who has access to edit that file once it's in the repo...) Another concept for the list: - We seek to make a decision that is: - Good enough for now, safe enough to try (i.e. it doesn't need to be perfect) - Moving us towards our shared goal - So we think of concerns and oppositions as gifts expressing a potential reason that the current proposal: - Isn't good enough for the current circumstances - Isn't safe enough to try - Hinders or endangers our progress towards the shared goal To avoid making the concepts list too long, I'll try to shorten the existing list to make room for this new stuff ^_^

The ### (a) Principles part may vary widely depending on who is involved in Forgejo and why. I think it will be extremely difficult to get people to agree on it. However, it is important to have a foundation to build on and I believe this is the intention. What about making that about "Core Values"? Things like "Free Software" or "Transparency"? I believe all people involved in Forgejo today may agree fairly quickly on a few core values ("Free Software" is obviously one of them 😄 ).

To clarify "Ask for the team's approval", there should be a definition of what a "team" is. It could be as simple as:

  • A "team" is the group of people who are impacted by a decision.

In "Ask people to make a +1 on each decision they're willing to live with, comfortable with" I find it slightly confusing that you're refering to multiple decision proposals. I expect the majority of cases will be about one decision for which there are variants because people do not agree and need to choose one of them. Not sure how to best phrase that.

The conclusion of (c) is "Once there's consensus,": what happens when there is no consensus?

I think "(d) And for major big project decisions?" is not necessary. The reality for every decision is that it starts with a discussion before a decision is proposed. For instance there are ongoing discussions about accessibility in Forgejo. This may very well lead to a decision proposal, referencing these discussions, that all changes implemented in Forgejo comply with some accessibility guidelines.

The `### (a) Principles` part may vary widely depending on who is involved in Forgejo and why. I think it will be extremely difficult to get people to agree on it. However, it is important to have a foundation to build on and I believe this is the intention. What about making that about "Core Values"? Things like "Free Software" or "Transparency"? I believe all people involved in Forgejo today may agree fairly quickly on a few core values ("Free Software" is obviously one of them 😄 ). To clarify "Ask for the team's approval", there should be a definition of what a "team" is. It could be as simple as: * A "team" is the group of people who are impacted by a decision. In "Ask people to make a +1 on each decision they're **willing to live with, comfortable with**" I find it slightly confusing that you're refering to multiple decision proposals. I expect the majority of cases will be about one decision for which there are variants because people do not agree and need to choose one of them. Not sure how to best phrase that. The conclusion of (c) is "Once there's consensus,": what happens when there is no consensus? I think "(d) And for major big project decisions?" is not necessary. The reality for every decision is that it starts with a discussion before a decision is proposed. For instance there are ongoing discussions about accessibility in Forgejo. This may very well lead to a decision proposal, referencing these discussions, that all changes implemented in Forgejo comply with some accessibility guidelines.
Contributor
Copy link

Hi all,
About the phrase

make the decision that will serve us the best

(emphasis mine), the best decision shouldn't be for the community, not (just) for the team? Perhaps forgejo community needs a minimal definition.

If the key question is What is important to you?, only people with a personal concern for the community could argue for the collective, does that mean that a personal agenda carries the same weight in terms of argumentation? So the key question sounds a bit individualistic.

Even further, as an example, I have received a response from the Gitea developers about a change involving accessibility:

From a development view, I do not think it's easy to make every developer(contributor) understand a11y clearly and write all dropdown elements with correct aria-attributes

If accessibility is going to be a concern for the whole project (and this could be the case for any other community value), this argument could involve a significant part of the team, but it would go against the community's concern.

So, why not rephrase the key question as What is important for the community??

s/Conflict = chance to connect, grow, learn/Conflict as an opportunity to connect, grow and learn/

Hi all, About the phrase >make the decision that will serve *us* the best (emphasis mine), the best decision shouldn't be for the community, not (just) for the team? Perhaps `forgejo community` needs a minimal definition. If the key question is **What is important to you?**, only people with a personal concern for the community could argue for the collective, does that mean that a personal agenda carries the same weight in terms of argumentation? So the key question sounds a bit individualistic. Even further, as an example, I have received a response from the Gitea developers about a change involving accessibility: >From a development view, I do not think it's easy to make every developer(contributor) understand a11y clearly and write all dropdown elements with correct aria-attributes If accessibility is going to be a concern for the whole project (and this could be the case for any other community value), this argument could involve a significant part of the team, but it would go against the community's concern. So, why not rephrase the key question as **What is important for the community?**? ----- `s/Conflict = chance to connect, grow, learn/Conflict as an opportunity to connect, grow and learn/`

Hi all,
About the phrase

make the decision that will serve us the best

(emphasis mine), the best decision shouldn't be for the community, not (just) for the team? Perhaps forgejo community needs a minimal definition.

What about?

make the decision that will best serve the general public

> Hi all, > About the phrase > > >make the decision that will serve *us* the best > > (emphasis mine), the best decision shouldn't be for the community, not (just) for the team? Perhaps `forgejo community` needs a minimal definition. What about? > make the decision that will best serve the general public
Contributor
Copy link

The ### (a) Principles part may vary widely depending on who is involved in Forgejo and why. I think it will be extremely difficult to get people to agree on it. However, it is important to have a foundation to build on and I believe this is the intention. What about making that about "Core Values"? Things like "Free Software" or "Transparency"? I believe all people involved in Forgejo today may agree fairly quickly on a few core values ("Free Software" is obviously one of them 😄 ).

I find the "Principles" part is really important, it's the basic idea of decision-making. If people have concerns about that part, that's okay, I'd like to hear the concerns and try to address them :-) Those principles are specifically about the decision-making technique, not principles of the Forgejo project. How does this sound to you?

As to core values like "software freedom" and "transparency", I suggest to put them in a values/vision document, not in the decision-making document (althoug of course the documents can refer to each other). I'll collect values and put a draft here for review, it's my task from the 1st meeting. Is that okay with you?

To clarify "Ask for the team's approval", there should be a definition of what a "team" is. It could be as simple as:

  • A "team" is the group of people who are impacted by a decision.

Tweaked the guidelines, will upload soon.

In "Ask people to make a +1 on each decision they're willing to live with, comfortable with" I find it slightly confusing that you're refering to multiple decision proposals. I expect the majority of cases will be about one decision for which there are variants because people do not agree and need to choose one of them. Not sure how to best phrase that.

I expect a single proposal for many decisions too, or variants of one proposal. But a single-proposal case is covered by the "general basic method" section. The "more complicated decisions" section handles a multiple-different-proposals scenario.

Would that work for now? (let's give people a chance to handle variants by identifying and addressing concerns)

The conclusion of (c) is "Once there's consensus,": what happens when there is no consensus?

Ask for help :-) There's no full recipe for decision-making, it's a skill to develop. The guide just explains the basic idea. Also, sometimes a decision is difficult because people are involved, they have feelings, and it can be very useful to have someone external facilitate the process, who can focus just on the process and allow everyone else to worry just about the topic of the decision. Will that work for now?

I think "(d) And for major big project decisions?" is not necessary. The reality for every decision is that it starts with a discussion before a decision is proposed. For instance there are ongoing discussions about accessibility in Forgejo. This may very well lead to a decision proposal, referencing these discussions, that all changes implemented in Forgejo comply with some accessibility guidelines.

I'm removing that part 👍

Will send updated version soon, once I address the other comments. Is there a place you prefer I send it? Or just upload as an attachment again?

> The `### (a) Principles` part may vary widely depending on who is involved in Forgejo and why. I think it will be extremely difficult to get people to agree on it. However, it is important to have a foundation to build on and I believe this is the intention. What about making that about "Core Values"? Things like "Free Software" or "Transparency"? I believe all people involved in Forgejo today may agree fairly quickly on a few core values ("Free Software" is obviously one of them 😄 ). I find the "Principles" part is really important, it's the basic idea of decision-making. If people have concerns about that part, that's okay, I'd like to hear the concerns and try to address them :-) Those principles are specifically about the decision-making technique, not principles of the Forgejo project. How does this sound to you? As to core values like "software freedom" and "transparency", I suggest to put them in a values/vision document, not in the decision-making document (althoug of course the documents can refer to each other). I'll collect values and put a draft here for review, it's my task from the 1st meeting. Is that okay with you? > > To clarify "Ask for the team's approval", there should be a definition of what a "team" is. It could be as simple as: > > * A "team" is the group of people who are impacted by a decision. Tweaked the guidelines, will upload soon. > In "Ask people to make a +1 on each decision they're **willing to live with, comfortable with**" I find it slightly confusing that you're refering to multiple decision proposals. I expect the majority of cases will be about one decision for which there are variants because people do not agree and need to choose one of them. Not sure how to best phrase that. I expect a single proposal for many decisions too, or variants of one proposal. But a single-proposal case is covered by the "general basic method" section. The "more complicated decisions" section handles a multiple-different-proposals scenario. Would that work for now? (let's give people a chance to handle variants by identifying and addressing concerns) > The conclusion of (c) is "Once there's consensus,": what happens when there is no consensus? Ask for help :-) There's no full recipe for decision-making, it's a skill to develop. The guide just explains the basic idea. Also, sometimes a decision is difficult because people are involved, they have feelings, and it can be very useful to have someone external facilitate the process, who can focus just on the *process* and allow everyone else to worry just about the *topic* of the decision. Will that work for now? > I think "(d) And for major big project decisions?" is not necessary. The reality for every decision is that it starts with a discussion before a decision is proposed. For instance there are ongoing discussions about accessibility in Forgejo. This may very well lead to a decision proposal, referencing these discussions, that all changes implemented in Forgejo comply with some accessibility guidelines. I'm removing that part 👍 Will send updated version soon, once I address the other comments. Is there a place you prefer I send it? Or just upload as an attachment again?
Contributor
Copy link

About the phrase

make the decision that will serve us the best

(emphasis mine), the best decision shouldn't be for the community, not (just) for the team? Perhaps forgejo community needs a minimal definition.

I'm rephrasing that line, using the word "us" in a more general way, and the community orientation will be addressed in the separate values and vision document, which is being prepared. Will that work?

Working with willingness and concerns allows us to work together as a team, to make good decisions about Forgejo, rather than competing for our voice to be heard and for our personal proposals to be picked

If the key question is What is important to you?, only people with a personal concern for the community could argue for the collective, does that mean that a personal agenda carries the same weight in terms of argumentation? So the key question sounds a bit individualistic.

Even further, as an example, I have received a response from the Gitea developers about a change involving accessibility:

From a development view, I do not think it's easy to make every developer(contributor) understand a11y clearly and write all dropdown elements with correct aria-attributes

If accessibility is going to be a concern for the whole project (and this could be the case for any other community value), this argument could involve a significant part of the team, but it would go against the community's concern.

So, why not rephrase the key question as What is important for the community??

I suppose as a default we hear all concerns. People who have personal concerns; people who self-host and care for their users; people who represent communities; people who reuse and repurpose our code in some expected original way... we hear them all.

Will this work: What's important to you? (or to the people/community you represent)

Additionally, the community topic will be addressed in the values document.

s/Conflict = chance to connect, grow, learn/Conflict as an opportunity to connect, grow and learn/

Switched from "chance" to "opportunity".

> About the phrase > > >make the decision that will serve *us* the best > > (emphasis mine), the best decision shouldn't be for the community, not (just) for the team? Perhaps `forgejo community` needs a minimal definition. I'm rephrasing that line, using the word "us" in a more general way, and the community orientation will be addressed in the separate *values and vision* document, which is being prepared. Will that work? *Working with willingness and concerns allows us to work together as a team, to make good decisions about Forgejo, rather than competing for our voice to be heard and for our personal proposals to be picked* > If the key question is **What is important to you?**, only people with a personal concern for the community could argue for the collective, does that mean that a personal agenda carries the same weight in terms of argumentation? So the key question sounds a bit individualistic. > Even further, as an example, I have received a response from the Gitea developers about a change involving accessibility: > > >From a development view, I do not think it's easy to make every developer(contributor) understand a11y clearly and write all dropdown elements with correct aria-attributes > > If accessibility is going to be a concern for the whole project (and this could be the case for any other community value), this argument could involve a significant part of the team, but it would go against the community's concern. > > So, why not rephrase the key question as **What is important for the community?**? I suppose as a default we hear all concerns. People who have personal concerns; people who self-host and care for their users; people who represent communities; people who reuse and repurpose our code in some expected original way... we hear them all. Will this work: What's important to you? (or to the people/community you represent) Additionally, the community topic will be addressed in the values document. > ----- > > `s/Conflict = chance to connect, grow, learn/Conflict as an opportunity to connect, grow and learn/` Switched from "chance" to "opportunity".
Contributor
Copy link

I agree that the values and vision should be in another document, I was just trying to show that decision-making should take that vision as its core, with the understanding that the team (the decision-maker) represents those values on behalf of the collective (the general public as @dachary said, or the different kind of users of forgejo as @fr33domlover said, etc. Community intended as all the people involved with the project, organized or not, but vinculated through forgejo as a common good).

Thank you for considering.

I agree that the values and vision should be in another document, I was just trying to show that decision-making should take that vision as its core, with the understanding that the team (the decision-maker) represents those values on behalf of the collective (the general public as @dachary said, or the different kind of users of forgejo as @fr33domlover said, etc. Community intended as all the people involved with the project, organized or not, but vinculated through forgejo as a common good). Thank you for considering.

I find the "Principles" part is really important, it's the basic idea of decision-making.

I get what you're after, thanks for explaining. I think it would be useful to me if the decision making process had two clearly separated: one that is a guide with advice and suggestions and another that lists the requirements. For instance:

Guide

  • Principles...
  • ...

Requirements

  • A period of no less than two weeks is required when asking for feedback
  • Decisions are recorded in the DECISIONS.md document
  • ...
> I find the "Principles" part is really important, it's the basic idea of decision-making. I get what you're after, thanks for explaining. I think it would be useful to me if the decision making process had two clearly separated: one that is a guide with advice and suggestions and another that lists the requirements. For instance: ### Guide * Principles... * ... ### Requirements * A period of no less than two weeks is required when asking for feedback * Decisions are recorded in the DECISIONS.md document * ...
Contributor
Copy link

I find the "Principles" part is really important, it's the basic idea of decision-making.

I get what you're after, thanks for explaining. I think it would be useful to me if the decision making process had two clearly separated: one that is a guide with advice and suggestions and another that lists the requirements. For instance:

Guide

  • Principles...
  • ...

Requirements

  • A period of no less than two weeks is required when asking for feedback
  • Decisions are recorded in the DECISIONS.md document
  • ...

I updated my document to have these 2 sections. However:

  • Instead of "requirements" I'm calling it "agreements", because I want to emphasize that we all agree out of our free will to follow them, rather than required by the force of some authority. The whole point of needs-based decision making is that nobody is required/forced to do anything, that's exactly what we're trying to prevent. What do you think? (and feel free to suggest another term)

  • I put the agreements part first, at the top, before the guide. Because I thought it should be very clearly visible and accessible, while the guide is just a helper tool.

> > I find the "Principles" part is really important, it's the basic idea of decision-making. > > > I get what you're after, thanks for explaining. I think it would be useful to me if the decision making process had two clearly separated: one that is a guide with advice and suggestions and another that lists the requirements. For instance: > > > ### Guide > > * Principles... > * ... > > ### Requirements > > * A period of no less than two weeks is required when asking for feedback > * Decisions are recorded in the DECISIONS.md document > * ... > > I updated my document to have these 2 sections. However: - Instead of "requirements" I'm calling it "agreements", because I want to emphasize that we all *agree out of our free will* to follow them, rather than *required by the force of some authority*. The whole point of needs-based decision making is that nobody is required/forced to do anything, that's exactly what we're trying to prevent. What do you think? (and feel free to suggest another term) - I put the agreements part first, at the top, before the guide. Because I thought it should be very clearly visible and accessible, while the guide is just a helper tool.

I'm fine with agreements, it is indeed less intimidating than requirements. As long as there is a clear understanding that an agreement is not subject to interpretation, it is not optional, it binary and no decision can be final without it.

I put the agreements part first, at the top, before the guide. Because I thought it should be very clearly visible and accessible, while the guide is just a helper tool.

👍

I'm fine with **agreements**, it is indeed less intimidating than **requirements**. As long as there is a clear understanding that an agreement is not subject to interpretation, it is not optional, it binary and no decision can be final without it. > I put the agreements part first, at the top, before the guide. Because I thought it should be very clearly visible and accessible, while the guide is just a helper tool. 👍
Contributor
Copy link

Attaching updated file. I put just a single agreement there, about how to document agreements. More agreements can be added once that file goes live, it can be a "test drive" for the system :)

Do you have more comments/concerns about this updated version?

And what do you think about the agreement I added in the file? It means all team members will have push access to to edit the agreement file(s), which implies we all trust each other in dealing with our agreement list.

If no further concerns, I'd like to have the whole team's approval about this document, because it's meaningless if people don't know about it and don't actively agree to work with it. @dachary, what do you think? What's the best place to gather everyone's consent and be sure everyone in the team is included? (asking you because I don't know the whole team and assuming you do?) Could also talk about it in monthly meeting, if I can attend at the time that gets chosen

Attaching updated file. I put just a single agreement there, about how to document agreements. More agreements can be added once that file goes live, it can be a "test drive" for the system :) Do you have more comments/concerns about this updated version? And what do you think about the agreement I added in the file? It means all team members will have push access to to edit the agreement file(s), which implies we all trust each other in dealing with our agreement list. If no further concerns, I'd like to have the whole team's approval about this document, because it's meaningless if people don't know about it and don't actively agree to work with it. @dachary, what do you think? What's the best place to gather everyone's consent and be sure everyone in the team is included? (asking you because I don't know the whole team and assuming you do?) Could also talk about it in monthly meeting, if I can attend at the time that gets chosen
Contributor
Copy link

Tasks for myself:

  • Process values into VALUES.md
  • Create agreement files
  • Create decision-making main document in forgejo/forgejo
  • Refer to it in CONTRIBUTING file
  • Explain the system to team, answer clarifying questions, gather consent

Tasks I'm proposing for other people ( @dachary , would you like to grab these?) to do once I'm done with mine, and of course ask me for help/clarification as needed

  • Add an agreement about our code of conduct
  • Add agreements about how PR review/approval/merging works?
Tasks for myself: - [Process values into VALUES.md](https://codeberg.org/forgejo/meta/issues/19#issuecomment-694460) - [x] Create agreement files - [x] Create decision-making main document in forgejo/forgejo - [x] Refer to it in CONTRIBUTING file - [ ] Explain the system to team, answer clarifying questions, gather consent Tasks I'm proposing for other people ( @dachary , would you like to grab these?) to do **once I'm done with mine**, and of course ask me for help/clarification as needed - [ ] Add an agreement about our code of conduct - [ ] Add agreements about how PR review/approval/merging works?

Add an agreement about our code of conduct

I'll do that.

Add agreements about how PR review/approval/merging works?

There is no agreement yet... it could very well be the first one!

> Add an agreement about our code of conduct I'll do that. > Add agreements about how PR review/approval/merging works? There is no agreement yet... it could very well be the first one!
Contributor
Copy link

Do you have more comments/concerns about this updated version?

That's good enough for me in the current circumstances. I would just like to know what the team is; I have not yet been able to listen to the 2022年12月10日 videoconference, so maybe I am a bit out of context.

> Do you have more comments/concerns about this updated version? > That's good enough for me in the current circumstances. I would just like to know what `the team` is; I have not yet been able to listen to the 2022年12月10日 videoconference, so maybe I am a bit out of context.

@fsologureng the teams are now documented at https://codeberg.org/forgejo/meta/src/branch/readme/TEAMS.md

@fsologureng the teams are now documented at https://codeberg.org/forgejo/meta/src/branch/readme/TEAMS.md
Contributor
Copy link

@fsologureng the teams are now documented at https://codeberg.org/forgejo/meta/src/branch/readme/TEAMS.md

Thank you.

The first part of the last draft indicate:

  1. Where to document agreements: When a decision is made, and it includes an agreement about how we do things, the person who brought the decision to the team records the agreement as follows:
    - If the agreement is about how we make decisions, it goes into this list here
    - 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
    - Otherwise, it goes into AGREEMENTS.md

Does it mean that a discussion in the context of a team could change Values.md or Agreements.md?

Not that I like hierarchies in particular, but there is an ambiguity in the scope of power of teams. If someone proposes the inclusion of a value for Forgejo, one would hope that at least all teams are included in the decision.

> @fsologureng the teams are now documented at https://codeberg.org/forgejo/meta/src/branch/readme/TEAMS.md Thank you. The first part of the last draft indicate: >1. **Where to document agreements:** When a decision is made, and it includes an agreement about how we do things, the person who brought the decision to the team records the agreement as follows: - If the agreement is about *how we make decisions*, it goes into this list here - 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` - Otherwise, it goes into `AGREEMENTS.md` Does it mean that a discussion in the context of a team could change Values.md or Agreements.md? Not that I like hierarchies in particular, but there is an ambiguity in the scope of power of teams. If someone proposes the inclusion of a value for Forgejo, one would hope that at least all teams are included in the decision.
Contributor
Copy link

There are mentions to Community leaders in the CONTRIBUTING/GOVERNANCE.md text. Perhaps that group should be mentioned in the decision.md for meta scope decisions.

There are mentions to `Community leaders` in the CONTRIBUTING/GOVERNANCE.md text. Perhaps that group should be mentioned in the decision.md for meta scope decisions.

There are mentions to Community leaders in the CONTRIBUTING/GOVERNANCE.md text. Perhaps that group should be mentioned in the decision.md for meta scope decisions.

I don't find such a wording in the history of modifications of this file. Am I missing something?

> There are mentions to `Community leaders` in the CONTRIBUTING/GOVERNANCE.md text. Perhaps that group should be mentioned in the decision.md for meta scope decisions. I don't find such a wording in the history of modifications of this file. Am I missing something?
Contributor
Copy link

There are mentions to Community leaders in the CONTRIBUTING/GOVERNANCE.md text. Perhaps that group should be mentioned in the decision.md for meta scope decisions.

I don't find such a wording in the history of modifications of this file. Am I missing something?

Sorry, I got lost among the links. Is in https://codeberg.org/forgejo/code-of-conduct#enforcement-responsibilities

> > There are mentions to `Community leaders` in the CONTRIBUTING/GOVERNANCE.md text. Perhaps that group should be mentioned in the decision.md for meta scope decisions. > > I don't find such a wording in the history of modifications of this file. Am I missing something? Sorry, I got lost among the links. Is in https://codeberg.org/forgejo/code-of-conduct#enforcement-responsibilities
Ghost modified the due date from 2022年12月10日 to 2022年12月17日 2022年12月14日 20:15:14 +01:00
Contributor
Copy link

@dachary shall we have another meeting, to go over the remaining open loops?

  • Integrate the things from the 1st meeting
  • Figure out foundational agreements, i.e. we want to trust the team members but what are the basic agreements that make the decision-making system explicit
  • Will the files in the CONTRIBUTING dir serve as agreements too, and then perhaps there's no need for AGREEMENTS.md
  • Evolve the format of TEAMS.md to include the purpose and accountability of each role
  • Discuss agreements about PR approval to make sure it's explicit

And perhaps the most important question:

  • Is the new system safeguarding us from repeating what happened to Gitea which lead to the Forgejo project in the first place?
@dachary shall we have another meeting, to go over the remaining open loops? - Integrate the things from the 1st meeting - Figure out foundational agreements, i.e. we want to trust the team members but what are the basic agreements that make the decision-making system explicit - Will the files in the CONTRIBUTING dir serve as agreements too, and then perhaps there's no need for AGREEMENTS.md - Evolve the format of TEAMS.md to include the purpose and accountability of each role - Discuss agreements about PR approval to make sure it's explicit And perhaps the most important question: - Is the new system safeguarding us from repeating what happened to Gitea which lead to the Forgejo project in the first place?

And perhaps the most important question:

  • Is the new system safeguarding us from repeating what happened to Gitea which lead to the Forgejo project in the first place?

Regardless of the Forgejo governance, Codeberg e.V. is the custodiant of the domains and trademark. This is what guarantees something similar won't happen with Forgejo. And allows the Forgejo community to figure out its governance in a collective way with no pressure on deadlines.

> And perhaps the most important question: > > * Is the new system safeguarding us from repeating what happened to Gitea which lead to the Forgejo project in the first place? > Regardless of the Forgejo governance, Codeberg e.V. is the custodiant of the domains and trademark. This is what guarantees something similar won't happen with Forgejo. And allows the Forgejo community to figure out its governance in a collective way with no pressure on deadlines.

@dachary shall we have another meeting, to go over the remaining open loops?

I'm available to participate in another meeting.

> @dachary shall we have another meeting, to go over the remaining open loops? I'm available to participate in another meeting.
Ghost removed the due date 2022年12月17日 2022年12月20日 23:56:34 +01:00

I like how https://codeberg.org/forgejo/meta/src/branch/readme/DECISION-MAKING.md is at the moment.

I share tallship concern about difficulties that may arise when the project includes a lot more people. It may be more difficult to reach consensus. I also think isolated voices / unique concerns tend to be silenced by the habit of trying to reach consensus.

An idea is to approach difficulties in decision making like it is done in threat modeling. Make a huge list of the difficulties and sort them according to probability and gravity. And work on ideas regarding how to deal with the most probable / serious.

I like how https://codeberg.org/forgejo/meta/src/branch/readme/DECISION-MAKING.md is at the moment. I share tallship concern about difficulties that may arise when the project includes a lot more people. It may be more difficult to reach consensus. I also think isolated voices / unique concerns tend to be silenced by the habit of trying to reach consensus. An idea is to approach difficulties in decision making like it is done in threat modeling. Make a huge list of the difficulties and sort them according to probability and gravity. And work on ideas regarding how to deal with the most probable / serious.

The recording of today's governance meeting (audio only) is here:

https://codeberg.org/forgejo/meta/src/branch/readme/2022-12-23-videoconference-governance.mp3

The recording of today's governance meeting (audio only) is here: https://codeberg.org/forgejo/meta/src/branch/readme/2022-12-23-videoconference-governance.mp3
Contributor
Copy link

Tasks from the meeting:

fr33:

  • Mention decision-making tools (CF etc.) in the docs, so that other people can find and learn them even if I disappear for some reason
  • Put a list of useful resources in the docs, about CF, approval voting, sociocracy etc. etc. so that curious team members can read and learn
  • Invite the team (probably via chatroom message), whoever is curious, motivated and has time, to learn CF, in order to increase bus factor and improve overall capacity for effective decision-making
  • CONTRIBUTING will serve as documentation, while actual agreements go into AGREEMENTS.md - document this somewhere? Probably in CONTRIBUTING
  • Update sections (b) and (b) in DECISION-MAKING.md to clarity the word "team"

Loic TODO list:

See the dedicated comment.

Open loops for next meeting:

  • Integrate the things from the 1st meeting
  • Discuss agreements about PR approval and pushing-to-branches to make sure it's explicit
  • Clarify wording "team" vs "organization" vs "circle"
  • Explicit system for expressing disapproval for the role that a team member has, and perhaps a limit on the amount of time a member holds a role without review (e.g. Loic suggested 1 year)
  • Foundational agreement about adding new members to the team / assigning new roles to members (e.g. introduce them to the decision-making system)

Goal for launching system: beginning of January i.e. roughly 2 weeks from now

Tasks from the meeting: fr33: - [x] Mention decision-making tools (CF etc.) in the docs, so that other people can find and learn them even if I disappear for some reason - [x] Put a list of useful resources in the docs, about CF, approval voting, sociocracy etc. etc. so that curious team members can read and learn - [x] Invite the team (probably via chatroom message), whoever is curious, motivated and has time, to learn CF, in order to increase bus factor and improve overall capacity for effective decision-making - [x] CONTRIBUTING will serve as documentation, while actual agreements go into AGREEMENTS.md - document this somewhere? Probably in CONTRIBUTING - [x] Update sections (b) and (b) in DECISION-MAKING.md to clarity the word "team" Loic TODO list: See [the dedicated comment](https://codeberg.org/forgejo/meta/issues/19#issuecomment-743899). Open loops for next meeting: - Integrate the things from the 1st meeting - Discuss agreements about PR approval and pushing-to-branches to make sure it's explicit - Clarify wording "team" vs "organization" vs "circle" - Explicit system for expressing disapproval for the role that a team member has, and perhaps a limit on the amount of time a member holds a role without review (e.g. Loic suggested 1 year) - Foundational agreement about adding new members to the team / assigning new roles to members (e.g. introduce them to the decision-making system) **Goal for launching system: beginning of January** i.e. roughly 2 weeks from now
Contributor
Copy link

Copying some thoughts from chat..

Governance

This governance is big scope, and you could think of it as an 'Epic'. Shouldn't it be split into several 'User stories'? This would make it easier for people that didn't attend the Governance meetings to get informed.

A quick glance at the long Governance discussion above and I see:

  • Governance
    • Organization structure
    • Decision making
    • Contributing
    • ...

Then Governance meeting could be announced: "Our agenda points today are [list of points]" and after the meeting point for point a summary and reference to update on the related governance sub-issue.

Even cleaner might be that each sub-issue is only open up-to the meeting, after which it is closed by a PR to a draft document on that subject, and a new issue with remaining open arguments created for the next meeting, while the Governance epic only tracks links to these issues.

There may be a Governance project board, where small-size issues fly across it. If I look at the discussion above it is TL;DR for me. Not possible to see what is open and what is done, and other participants also mention they get lost in the links.

Project tracks

In general it may not be a bad idea to have long-running project tracks, which are effectively projects within the Forgejo project. The code project is what you usually think of as THE project. But Governance improvement is also like a project. Architecture could be one, UX Design could be one, Research could be one.

Have boards for them, same as for technical issues.
If there is a team division, within each team there can be 'backlog grooming' to split overly long issues into bite-size ones that can be done relatively quickly and/or split into Epic/Userstory summary issues where that is needed.

Copying some thoughts [from chat](https://matrix.to/#/!qjPHwFPdxhpLkXMkyP:matrix.org/$x5JG13geEGrWNjsqEIvnKr9Bz33UNJjU8asNdkzrlB0?via=matrix.org&via=tchncs.de&via=exozy.me).. ### Governance This governance is big scope, and you could think of it as an 'Epic'. Shouldn't it be split into several 'User stories'? This would make it easier for people that didn't attend the Governance meetings to get informed. A quick glance at the long Governance discussion above and I see: - Governance - [ ] Organization structure - [ ] Decision making - [ ] Contributing - [ ] ... Then Governance meeting could be announced: "Our agenda points today are [list of points]" and after the meeting point for point a summary and reference to update on the related governance sub-issue. Even cleaner might be that each sub-issue is only open up-to the meeting, after which it is closed by a PR to a draft document on that subject, and a new issue with remaining open arguments created for the next meeting, while the Governance epic only tracks links to these issues. There may be a Governance project board, where small-size issues fly across it. If I look at the discussion above it is TL;DR for me. Not possible to see what is open and what is done, and other participants also mention they get lost in the links. ### Project tracks In general it may not be a bad idea to have long-running project tracks, which are effectively projects within the Forgejo project. The code project is what you usually think of as THE project. But Governance improvement is also like a project. Architecture could be one, UX Design could be one, Research could be one. Have boards for them, same as for technical issues. If there is a team division, within each team there can be 'backlog grooming' to split overly long issues into bite-size ones that can be done relatively quickly and/or split into Epic/Userstory summary issues where that is needed.

My TODO list

  • Add purpose, accountabilities & maintained resources for all teams in TEAMS.md (coordinate/consult with those teams as needed, make sure they approve the accountabilities listed for them)
  • Add role duration for security team in TEAMS.md, after discussing with the 4 people listed in security team
  • Add an agreement about transparency about funding / financial interests (make sure the team indeed agrees on this)
    @fr33domlover I will postpone this until later. I think it is an agreement that will require long discussions and may be best discussed once the decision process settles and is agreed upon with easier agreements.
  • Add a value about transparency in VALUES.md?
My TODO list - [ ] Add purpose, accountabilities & maintained resources for all teams in TEAMS.md (coordinate/consult with those teams as needed, make sure they approve the accountabilities listed for them) * Proposed in [a pull request](https://codeberg.org/forgejo/meta/pulls/79) - [ ] Add role duration for security team in TEAMS.md, after discussing with the 4 people listed in security team * [Question in the chatroom](https://matrix.to/#/!qjPHwFPdxhpLkXMkyP:matrix.org/$KVptveURj6wRDgMJuuXPShasYfEaUCBuH22W8rwbxHA?via=matrix.org&via=tchncs.de&via=exozy.me) - [x] Add an agreement about transparency about funding / financial interests (make sure the team indeed agrees on this) @fr33domlover I will postpone this until later. I think it is an agreement that will require long discussions and may be best discussed once the decision process settles and is agreed upon with easier agreements. - [x] Add a value about transparency in VALUES.md? * Proposed in [a pull request](https://codeberg.org/forgejo/meta/pulls/78)
Contributor
Copy link

In follow-up to my comment just above, and @dachary response on chat copied here:

Some thoughts on Governance discussion. This is big scope, and you could think of it as an 'Epic'. Shouldn't it be split into several 'User stories'? This would make it easier for people that didn't attend the Governance meetings to get informed.

I'm generally happy with whatever organization the person leading the effort prefers (that would be
fr33domlover in this case). If you were to organize the governance effort as you describe, I would also happily participate and adapt. I guess I don't have strong opinions when it comes to administrative overhead (or lack of overhead) 😄 Although I sometime get bored if the organizational structure is discussed more extensively than the work at hand, but that did not happen so far, IMHO.

I would like to share some more thoughts.

What is Governance?

It is not yet fully clear to me how Forgejo considers Governance. In other words, what does Governance govern? To me governance is not just a parallel track of defining project structure and procedures, but rather Governance is the overarching process that ensures an inclusive and healthy community collaborates on the Forgejo software development project fruitfully and productively.

Governance then encompasses:

  • The entirety of project structure and community organization.
  • The entirety of ongoing processes and procedures.

Governance is the ongoing work of everyone involved in Forgejo in some way or other. The top-level process.

  • It is a governance decision to have a Project Board.
  • It is a governance procedure how the workflow of that board is organized.
  • It is a governance process to monitor how the workflow can be improved.

All this doesn't necessarily need a lot of formality. A project board creation may not need a Vote. It depends. When that is required or not may be a governance procedure.

I am typing this in hopes to make clear this isn't about "administrative overhead", but rather about "what everyone does, why they do it, and how they do it". Preferably with minimal overhead and in ways they are used to working already. With objective to make participation fun and productive, while also ensuring all voices are heard appropriately and chores are spread fairly among members.

Project tracks revisited

Some examples for the Governance project track..

One thing that also triggered me to type this comment now, are the length of Discussion type meta issues. Such as this one, which is TL;DR for most people. And also Cleanup Chores #81 that using the label "Recurring" indicate an ongoing process.

Besides becoming TL;DR causing people not to inform themselves, these issues cannot be closed from the backlog as "Work done" and subsequent comments are missed. In #81 @dachary volunteers for doing the chore and hopes others will also come to help. But the monthly additional comment to #81 of cleanup actions will be missed by everyone and people are silently happy to let Loïc do that chore.

So ongoing Governance process identifies an opportunity to improve..

In a new Governance issue it proposes that:

  • A new Cleanup task (a Governance issue) travels the Governance board on a monthly basis.
  • Either a Cleanup log with issue list is tracked, or a Cleanup label created.
  • In the monthly report there will be mention of who did the chores.

The Governance issue is accepted, documented somewhere, and from then on it works as proposed. Now everyone is aware of the chore, as it pops up on the board. @dachary self-assigns the issue, if no one else takes it.

In addition to continual improvement of the Governance process, Forgejo - being a software forge project - can derive product features from its own development process. Our own process and improvement opportunities constitute user feedback, input to User Research.

Every software project has governance. Every project has chores. All too often these are wholly implicit, and hence under-appreciated.

In the procedure above a new product feature can be gleaned:

  • Recurring tasks: An issue that is automatically created on a specified time interval. It can be based on an issue template and auto-added to a project board.
In follow-up to [my comment](https://codeberg.org/forgejo/meta/issues/19#issuecomment-743853) just above, and @dachary response on [chat](https://matrix.to/#/!qjPHwFPdxhpLkXMkyP:matrix.org/$MJq1YZEMOAs88qCPUZe8IBrQ08Hit_clG41OY06GgvI?via=matrix.org&via=tchncs.de&via=exozy.me) copied here: >> Some thoughts on Governance discussion. This is big scope, and you could think of it as an 'Epic'. Shouldn't it be split into several 'User stories'? This would make it easier for people that didn't attend the Governance meetings to get informed. > >I'm generally happy with whatever organization the person leading the effort prefers (that would be fr33domlover in this case). If you were to organize the governance effort as you describe, I would also happily participate and adapt. I guess I don't have strong opinions when it comes to administrative overhead (or lack of overhead) 😄 Although I sometime get bored if the organizational structure is discussed more extensively than the work at hand, but that did not happen so far, IMHO. I would like to share some more thoughts. ### What is Governance? It is not yet fully clear to me how Forgejo considers Governance. In other words, what does Governance govern? To me governance is not just a parallel track of defining project structure and procedures, but rather Governance is the overarching process that ensures an inclusive and healthy community collaborates on the Forgejo software development project fruitfully and productively. Governance then encompasses: - The entirety of project structure and community organization. - The entirety of ongoing processes and procedures. Governance is the ongoing work of everyone involved in Forgejo in some way or other. The top-level process. - It is a governance decision to have a Project Board. - It is a governance procedure how the workflow of that board is organized. - It is a governance process to monitor how the workflow can be improved. All this doesn't necessarily need a lot of formality. A project board creation may not need a Vote. It depends. When that is required or not _may_ be a governance procedure. I am typing this in hopes to make clear this isn't about "administrative overhead", but rather about "what everyone does, why they do it, and how they do it". Preferably with minimal overhead and in ways they are used to working already. With objective to make participation fun and productive, while also ensuring all voices are heard appropriately and chores are spread fairly among members. #### Project tracks revisited Some examples for the Governance project track.. One thing that also triggered me to type this comment now, are the length of Discussion type meta issues. Such as this one, which is TL;DR for most people. And also [Cleanup Chores #81](https://codeberg.org/forgejo/meta/issues/81) that using the label "Recurring" indicate an ongoing process. Besides becoming TL;DR causing people not to inform themselves, these issues cannot be closed from the backlog as "Work done" and subsequent comments are missed. In #81 @dachary volunteers for doing the chore and hopes others will also come to help. But the monthly additional comment to #81 of cleanup actions will be missed by everyone and people are silently happy to let Loïc do that chore. So ongoing Governance process identifies an opportunity to improve.. In a new Governance issue it proposes that: - A new Cleanup task (a Governance issue) travels the Governance board on a monthly basis. - Either a Cleanup log with issue list is tracked, or a Cleanup label created. - In the monthly report there will be mention of who did the chores. The Governance issue is accepted, documented somewhere, and from then on it works as proposed. Now everyone is aware of the chore, as it pops up on the board. @dachary self-assigns the issue, if no one else takes it. --- In addition to continual improvement of the Governance process, Forgejo - being a software forge project - can derive product features from its own development process. Our own process and improvement opportunities constitute user feedback, input to User Research. Every software project has governance. Every project has chores. All too often these are wholly implicit, and hence under-appreciated. In the procedure above a new product feature can be gleaned: - **Recurring tasks**: An issue that is automatically created on a specified time interval. It can be based on an issue template and auto-added to a project board.

One thing that also triggered me to type this comment now, are the length of Discussion type meta issues. Such as this one, which is TL;DR for most people. And also Cleanup Chores #81 that using the label "Recurring" indicate an ongoing process.

On the positive, having a single issue is convenient to quickly browse what was done in the past, Control-F to find particular strings. Most people won't read all of it but they may read the last few entries and find they can contribute. It's also a good way to see that progress is actually made on a regular basis.

It feels to me like it is the right way to do this at the moment. Besides, it will happen once every month so 12 entries per year. I'm not convince it will be overwhelming.

> One thing that also triggered me to type this comment now, are the length of Discussion type meta issues. Such as this one, which is TL;DR for most people. And also Cleanup Chores #81 that using the label "Recurring" indicate an ongoing process. On the positive, having a single issue is convenient to quickly browse what was done in the past, Control-F to find particular strings. Most people won't read all of it but they may read the last few entries and find they can contribute. It's also a good way to see that progress is actually made on a regular basis. It feels to me like it is the right way to do this at the moment. Besides, it will happen once every month so 12 entries per year. I'm not convince it will be overwhelming.
Contributor
Copy link

@circlebuilder, thank you for deeply thinking and expressing these things.

Right now, we're just bootstrapping the decision-making system. We aren't deciding who does what and how. We're just laying out the process for making and documenting decisions. Once that's in place, the team can use the process to make any decision. Who does what. And how and when. How to welcome new contributors, where to push the code, and what's the organizational structure.

Clear publishing of agenda and summary: If doing that via comments here is difficult for interested people to track, I'm happy to do it some other way. Do you have a suggestion? Forgejo doesn't have a forum, or an official document storage place. Open an issue for each meeting? Also, where would you document and track micro-tasks? I've been doing that using the - [ ] syntax in comments on this issue. Willing to do it differently if you have ideas.

What is governance: Describing and listing requirements for the system itself can surely be beneficial and useful, both for evolving it and for documenting it. But I think it may be too early for that, because we're still experimenting. Would it work for you, for now, to move your comment into a new issue, and for us to revisit it once the decision-making system (draft) is officially introduced to the whole team? Also, check out the VALUES.md file; it's a good place to add a value like "Inclusion", from which we can then make more specific decisions.

Everything else: Can you move things into a new issue(s)?

@circlebuilder, thank you for deeply thinking and expressing these things. Right now, we're just *bootstrapping* the *decision-making* system. We aren't deciding who does what and how. We're just laying out the *process* for making and documenting decisions. Once that's in place, the team can use the process to make any decision. Who does what. And how and when. How to welcome new contributors, where to push the code, and what's the organizational structure. Clear publishing of agenda and summary: If doing that via comments here is difficult for interested people to track, I'm happy to do it some other way. Do you have a suggestion? Forgejo doesn't have a forum, or an official document storage place. Open an issue for each meeting? Also, where would you document and track micro-tasks? I've been doing that using the `- [ ]` syntax in comments on this issue. Willing to do it differently if you have ideas. What is governance: Describing and listing requirements for the system itself can surely be beneficial and useful, both for evolving it and for documenting it. But I think it may be too early for that, because we're still *experimenting*. Would it work for you, for now, to move your comment into a new issue, and for us to revisit it once the decision-making system (draft) is officially introduced to the whole team? Also, check out the `VALUES.md` file; it's a good place to add a value like "Inclusion", from which we can then make more specific decisions. Everything else: Can you move things into a new issue(s)?

@circlebuilder would you like to take an active role in the making of the governance? Or are you happy in a (very appreciated) mentoring role providing advice for people working on the governance to better organize their work?

@circlebuilder would you like to take an active role in the making of the governance? Or are you happy in a (very appreciated) mentoring role providing advice for people working on the governance to better organize their work?
Contributor
Copy link

@dachary @fr33domlover in this comment #14 (comment) about Social Coding practitioner I mention the role I prefer. In a kind of double-linking relationship to Social Coding Movement.

The reason I do not want to commit to a true role in Forgejo is that I have several very big projects simmering above the frying pan already. The very big total scope of that makes progress go slowly, but I am content with that. But it means I cannot add more projects to that workload (and personally info overload is an eternal struggle).

Right now, we're just bootstrapping the decision-making system.

Yes, I got that. My feedback is also input to bootstrapping. Note that the most important part of my feedback is: What place does Governance have in the overall project organization? Where I see it as a top-level concept from where all development processes are related (in other words, if they are not, they aren't governed but implicit).

Open an issue for each meeting? Also, where would you document and track micro-tasks?

That would be an idea, yes. Note that the checkbox format - [ ] Description (sub-issue-link) is I think only effective in the top-level issue text (only place where the UI tracks sub-tasks) rather than mid-thread.

Another option might be meeting markdown notes, that initially just have agenda announcement, and are completed with meeting notes afterwards (though PR workflows are a bit clumsy for working on text docs).

Yet another option (Bonfire had this for a while, I think) is a single HedgeDoc pad at a fixed location that has meeting announcement + agenda at the top, and then below the history of all past meetings. Everything in a single doc. (This may need to have non-public editing rights to avoid vandalism).

Forgejo doesn't have a forum

It is weird, but I find it way more difficult to parse long discussions on the issue tracker, than I have on Discourse forums. Long issues are TL;DR much quicker somehow.

In aforementioned comment I offer Social Coding top-level forum space and staff accounts for Forgejo. If Forgejo were to accept the offer, the scope of that space won't be as broad as e.g. the Gitea forum for their project (a user asking "How do I install Forgejo?" is off-topic for Social Coding).

But the specific Governance of Forgejo is in scope, same as "Forgejo Labs" research including federation and UX/UI designs for new product features.

(Just mentioning. I will list that scope on #14 in a separate comment) --> Update: See this comment.

Describing and listing requirements for the system itself can surely be beneficial and useful, both for evolving it and for documenting it. But I think it may be too early for that, because we're still experimenting. Would it work for you, for now, to move your comment into a new issue.

Yes, I guess I can split out into more bite-size issues on the Meta backlog.

@dachary @fr33domlover in this comment https://codeberg.org/forgejo/meta/issues/14#issuecomment-746875 about Social Coding practitioner I mention the role I prefer. In a kind of double-linking relationship to Social Coding Movement. The reason I do not want to commit to a true role in Forgejo is that I have several very big projects simmering above the frying pan already. The very big total scope of that makes progress go slowly, but I am content with that. But it means I cannot add more projects to that workload (and personally info overload is an eternal struggle). > Right now, we're just bootstrapping the decision-making system. Yes, I got that. My feedback is also input to bootstrapping. Note that the most important part of my feedback is: What place does Governance have in the overall project organization? Where I see it as a top-level concept from where all development processes are related (in other words, if they are not, they aren't governed but implicit). > Open an issue for each meeting? Also, where would you document and track micro-tasks? That would be an idea, yes. Note that the checkbox format `- [ ] Description (sub-issue-link)` is I think only effective in the top-level issue text (only place where the UI tracks sub-tasks) rather than mid-thread. Another option might be meeting markdown notes, that initially just have agenda announcement, and are completed with meeting notes afterwards (though PR workflows are a bit clumsy for working on text docs). Yet another option (Bonfire had this for a while, I think) is a single HedgeDoc pad at a fixed location that has meeting announcement + agenda at the top, and then below the history of all past meetings. Everything in a single doc. (This may need to have non-public editing rights to avoid vandalism). > Forgejo doesn't have a forum It is weird, but I find it way more difficult to parse long discussions on the issue tracker, than I have on Discourse forums. Long issues are TL;DR much quicker somehow. In aforementioned comment I offer Social Coding top-level forum space and staff accounts for Forgejo. If Forgejo were to accept the offer, the scope of that space won't be as broad as e.g. the Gitea forum for their project (a user asking "How do I install Forgejo?" is off-topic for Social Coding). But the specific Governance of Forgejo is in scope, same as "Forgejo Labs" research including federation and UX/UI designs for new product features. (Just mentioning. I will list that scope on #14 in a separate comment) --> **Update**: See [this comment](https://codeberg.org/forgejo/meta/issues/14#issuecomment-748237). > Describing and listing requirements for the system itself can surely be beneficial and useful, both for evolving it and for documenting it. But I think it may be too early for that, because we're still experimenting. Would it work for you, for now, to move your comment into a new issue. Yes, I guess I can split out into more bite-size issues on the Meta backlog.

@fr33domlover do you have plans for another governance videoconference?

@fr33domlover do you have plans for another governance videoconference?

@fr33domlover gentle ping?

@fr33domlover gentle ping?
Contributor
Copy link

@dachary Yes! Will Monday work? i.e. January 16? I prefer europe morning/afternoon - which times on Monday will work for you?

Other days I'm available in the coming week to schedule: Friday, Saturday.

Do you need to schedule more time in advance?

And anyone else who wants to participate, provide your input as well.

@dachary Yes! Will Monday work? i.e. January 16? I prefer europe morning/afternoon - which times on Monday will work for you? Other days I'm available in the coming week to schedule: Friday, Saturday. Do you need to schedule more time in advance? And anyone else who wants to participate, provide your input as well.

Next week Friday 20 will be good for me.

Next week Friday 20 will be good for me.
Contributor
Copy link

Transferring some relevant chat info. @fr33domlover mentioned:

Replying to the governance related discussion: It's making me wonder how things would look if Forgejo has that amount of people and development action that Gitea has - what would our governance structure look like? What does a human-wellbeing-and-needs oriented governance structure look like?

A quick rough idea I'm imagining:

  • To have a board of people, who are relevant stakeholders or representing relevant stakeholders, and who meet regularly to shape the project's roadmap
  • There's a circle of trusted people, the project's guardians, possibly a subgroup of the board, who together collect the stakeholders and have some powers in steering the project, to make sure the project is safe even if some stealthy takeover somehow occurs
  • There's a teams structure, much like the one we're now having/creating
  • Explicit instructions for reviewing PRs based on the roadmap, allowing some DoOcracy-based freedom within the project's vision / values / social contract
  • If funds are coming in, have an explicit system for financial support for people involved in the project, ideally one based on people's needs (gift economy) and on their contribution with respect to the explicit public roadmap

Now I'm more calm, having some initial idea of what could serve a collaborative free software project ^_^

And I followed-up with an analogy that may be handy when thinking of Governance:

To what fr33domlover summarized I would add that Governance can be considered in an analogy to building software, only in this case it is about 'building process'. What the governance bootstrap issue has done is thinking about requirements, elaborated about some architecture / design, and fr33's summary is like a roadmap planning. Governance we have now already, is like the MVP (you may say "minimum viable process"). Improving the Governance is ongoing / iterative project track. Fine-tuning procedures, adding "features" based on a need, and what has shown to work. Making this analogy to software development may make it easier to wrap one's head around how Governance is intertwined in the project and how it evolves.

Note that when I think "Governance" I think of the entirety of ALL processes and procedures that are related in some way or other with the "Forgejo initiative" (avoiding "project" here, as it is a bit of an overloaded term), and involving ALL stakeholders (where "stakeholder" is literally anyone that is somehow affected by Forgejo). Governance is like "the glue" of the Free Software Development Lifecycle (FSDL) that holds this complex initiative together. The "infrastructure" where improvements are done with CI in the software analogy.

Transferring some relevant chat info. @fr33domlover [mentioned](https://matrix.to/#/!qjPHwFPdxhpLkXMkyP:matrix.org/$oGCLZKvxJCTSICi_2X9sSBKtwTnp3ElM8KEd6s-i3OI?via=matrix.org&via=envs.net&via=tchncs.de): > Replying to the governance related discussion: It's making me wonder how things would look if Forgejo has that amount of people and development action that Gitea has - what would our governance structure look like? What does a human-wellbeing-and-needs oriented governance structure look like? > > A quick rough idea I'm imagining: > > - To have a board of people, who are relevant stakeholders or representing relevant stakeholders, and who meet regularly to shape the project's roadmap > - There's a circle of trusted people, the project's guardians, possibly a subgroup of the board, who together collect the stakeholders and have some powers in steering the project, to make sure the project is safe even if some stealthy takeover somehow occurs > - There's a teams structure, much like the one we're now having/creating > - Explicit instructions for reviewing PRs based on the roadmap, allowing some DoOcracy-based freedom within the project's vision / values / social contract > - If funds are coming in, have an explicit system for financial support for people involved in the project, ideally one based on people's needs (gift economy) and on their contribution with respect to the explicit public roadmap > > Now I'm more calm, having some initial idea of what could serve a collaborative free software project ^_^ And I [followed-up](https://matrix.to/#/!qjPHwFPdxhpLkXMkyP:matrix.org/$jdflwX3kV2ArvxXgZbG7endlOlzDUIIGgPAQUfzz3TM?via=matrix.org&via=envs.net&via=tchncs.de) with an analogy that may be handy when thinking of Governance: > To what fr33domlover summarized I would add that Governance can be considered in an analogy to building software, only in this case it is about 'building process'. What the governance bootstrap issue has done is thinking about requirements, elaborated about some architecture / design, and fr33's summary is like a roadmap planning. Governance we have now already, is like the MVP (you may say "minimum viable process"). Improving the Governance is ongoing / iterative project track. Fine-tuning procedures, adding "features" based on a need, and what has shown to work. Making this analogy to software development may make it easier to wrap one's head around how Governance is intertwined in the project and how it evolves. > > Note that when I think "Governance" I think of the entirety of ALL processes and procedures that are related in some way or other with the "Forgejo initiative" (avoiding "project" here, as it is a bit of an overloaded term), and involving ALL stakeholders (where "stakeholder" is literally anyone that is somehow affected by Forgejo). Governance is like "the glue" of the Free Software Development Lifecycle (FSDL) that holds this complex initiative together. The "infrastructure" where improvements are done with CI in the software analogy.
Contributor
Copy link

Wrt comment above:

@dachary @fr33domlover in this comment #14 about Social Coding practitioner I mention the role I prefer. In a kind of double-linking relationship to Social Coding Movement.

I'd like to officially mention that I want to be liaison between Social Coding Movement and Forgejo, from the Social Coding side, and help @fr33domlover improve Forgejo Governance from that perspective.

Wrt [comment above](): > @dachary @fr33domlover in this comment [#14](https://codeberg.org/forgejo/meta/issues/14#issuecomment-746875) about Social Coding practitioner I mention the role I prefer. In a kind of double-linking relationship to Social Coding Movement. I'd like to officially mention that I want to be liaison between Social Coding Movement and Forgejo, from the Social Coding side, and help @fr33domlover improve Forgejo Governance from that perspective.
Contributor
Copy link

In follow up to @fsologureng commenting to @dachary on ongoing UX as a discipline versus doing separate User Research, here's my take..

TL;DR both "inclusive project" and "agile process" favor multi-disciplinary project activity. Ongoing day-to-day design and coding tasks should occur in the same issue tracker and chatrooms. And then there are parallel project tracks, like e.g. Product development where larger chunks, not directly actionable, are elaborated.

Diverse community --> Multi-disciplinary activity

Having a diverse community is one of the core objectives of Forgejo, and soft fork from Gitea ensures its community control. In terms of Governance how processes are defined will impact inclusion and encourage diversity.

When analysing project activity it may be tempting to divide tasks into different separate tracks. But beware, this can be detrimental to inclusion. And also it may impact output, the product deliverable, negatively.

Agile development in companies became popular for the observation of silo's within the organization and handover boundaries between separated teams that were highly inefficient. And to mitigate that, teams are multi-disciplinary.

E.g. in Scrum a team will have developer, tester, UX designer, scrum master (project manager), product owner (product manager) and sometimes business analyst roles. They are all exposed to each others daily tasks and hence much more informed on what's important, and having a more holistic overview of the project status and better communication.

Project tracks vs Agile development

In FOSS projects, like Forgejo, different approach to agile in companies need to be taken. There are no employees physically present, few full-time workers and many people in the broader community that may contribute bits and pieces.

In the most active, generic communication channels is where multi-disciplinary collaboration starts, and then it is taken further into specific repo's and their issue trackers.

I'd highly encourage fostering this multi-disciplinary focus, even if it means that communication in the general chatroom gets messier. A weakness in FOSS is imho dogmatic tech focus that often prevails, in code repositories but also channels dedicated to this.

@fsologureng mentioned UX bugs and minor improvements as example of where things should be part of daily practice, multi-disciplinary. I argue that the same holds for Accessibility. If a button is missing an aria-attribute, that should be brought up in a more chatroom than one dedicated to a11y only. You gain awareness of a11y that way.

So when do we better have separate project tracks?

When an ongoing process runs in parallel to core software development track, and relates to activities that aren't immediately actionable or aren't related directly to the project itself.

Possible project tracks:

  • Governance: Continual improvement of the development process. Sustainability and fundraising are part of this.. they are result of good governance.
  • Product development: Designing and planning for future software development. User research is part of this, i.e. design of new/improved UX/UI. Big a11y chunks are found here too.
  • Research: Focusing on innovations, after which topics transition to product development. And stuff eventually makes it into production code.

Note: Related are my comments on no. of chatrooms, now closed.

In follow up to @fsologureng [commenting](https://codeberg.org/forgejo/forgejo/issues/241#issuecomment-771836) to @dachary on ongoing UX as a discipline versus doing separate User Research, here's my take.. **TL;DR** both "inclusive project" and "agile process" favor multi-disciplinary project activity. Ongoing day-to-day design and coding tasks should occur in the same issue tracker and chatrooms. And then there are parallel project tracks, like e.g. Product development where larger chunks, not directly actionable, are elaborated. ## Diverse community --> Multi-disciplinary activity Having a diverse community is one of the core objectives of Forgejo, and soft fork from Gitea ensures its community control. In terms of Governance how processes are defined will impact inclusion and encourage diversity. When analysing project activity it may be tempting to divide tasks into different separate tracks. But beware, this can be detrimental to inclusion. And also it may impact output, the product deliverable, negatively. Agile development in companies became popular for the observation of silo's within the organization and handover boundaries between separated teams that were highly inefficient. And to mitigate that, teams are multi-disciplinary. E.g. in Scrum a team will have developer, tester, UX designer, scrum master (project manager), product owner (product manager) and sometimes business analyst roles. They are all exposed to each others daily tasks and hence much more informed on what's important, and having a more holistic overview of the project status and better communication. ## Project tracks vs Agile development In FOSS projects, like Forgejo, different approach to agile in companies need to be taken. There are no employees physically present, few full-time workers and many people in the broader community that may contribute bits and pieces. In the most active, generic communication channels is where multi-disciplinary collaboration starts, and then it is taken further into specific repo's and their issue trackers. I'd highly encourage fostering this multi-disciplinary focus, even if it means that communication in the general chatroom gets messier. A weakness in FOSS is imho dogmatic tech focus that often prevails, in code repositories but also channels dedicated to this. @fsologureng mentioned UX bugs and minor improvements as example of where things should be part of daily practice, multi-disciplinary. I argue that the same holds for Accessibility. If a button is missing an aria-attribute, that should be brought up in a more chatroom than one dedicated to a11y only. You gain awareness of a11y that way. So when do we better have separate project tracks? When an ongoing process runs in parallel to core software development track, and relates to activities that aren't immediately actionable or aren't related directly to the project itself. Possible project tracks: - **Governance**: Continual improvement of the development process. Sustainability and fundraising are part of this.. they are result of good governance. - **Product development**: Designing and planning for future software development. User research is part of this, i.e. design of new/improved UX/UI. Big a11y chunks are found here too. - **Research**: Focusing on innovations, after which topics transition to product development. And stuff eventually makes it into production code. Note: Related are [my comments](https://codeberg.org/forgejo/meta/issues/77#issuecomment-740948) on no. of chatrooms, now closed.
Contributor
Copy link

@dachary

Next week Friday 20 will be good for me.

I can Friday too, ideally a bit later or before; 18hrs is lunch time hear

@dachary >Next week Friday 20 will be good for me. I can Friday too, ideally a bit later or before; 18hrs is lunch time hear
Contributor
Copy link

Friday, January 20 works for me. As for the time: Will 12:00 - 13:30 UTC comfortably work for you? @dachary , @fsologureng , anyone else who's interested?

Friday, January 20 works for me. As for the time: Will 12:00 - 13:30 UTC comfortably work for you? @dachary , @fsologureng , anyone else who's interested?

Noted in my agenda. I really look forward to this: it feels like a decision making process is near 🎉

Here is a contribution to the agenda:

  • Decision making process
  • Teams which team should go first to resign / be appointed according to the decision making process?
  • How to move forward for copyleft?
  • How to move forward for paid staff commitment?
Noted in my agenda. I really look forward to this: it feels like a decision making process is near 🎉 Here is a contribution to the agenda: * Decision making process * Teams which team should go first to resign / be appointed according to the decision making process? * How to move forward for [copyleft](https://codeberg.org/forgejo/meta/issues/86)? * How to move forward for [paid staff commitment](https://codeberg.org/forgejo/meta/issues/104)?
Contributor
Copy link

@fsologureng mentioned UX bugs and minor improvements as example of where things should be part of daily practice, multi-disciplinary. I argue that the same holds for Accessibility. If a button is missing an aria-attribute, that should be brought up in a more chatroom than one dedicated to a11y only. You gain awareness of a11y that way.

I think is a good idea work together both UX and accessibility, because earlier shared decisions generate less friction and problems after.

> @fsologureng mentioned UX bugs and minor improvements as example of where things should be part of daily practice, multi-disciplinary. I argue that the same holds for Accessibility. If a button is missing an aria-attribute, that should be brought up in a more chatroom than one dedicated to a11y only. You gain awareness of a11y that way. I think is a good idea work together both UX and accessibility, because earlier shared decisions generate less friction and problems after.
Contributor
Copy link

@dachary @fsologureng can you comment your agenda items in #112 ?

@dachary @fsologureng can you comment your agenda items in #112 ?
Contributor
Copy link

I think that lack of governance agreements is starting to become a problem of legitimacy; We should push to resolve this issue as soon as possible to prevent that scenario.

At least we need an agreement in order to define how to address a pull request.

I think that lack of governance agreements is starting to become a problem of legitimacy; We should push to resolve this issue as soon as possible to prevent that scenario. At least we need an agreement in order to define how to address a pull request.

@fsologureng I agree this is becoming an issue. Would you like to bootstrap a discussion on that particular point? I think we have enough in terms of decision making to make that happen now.

@fsologureng I agree this is becoming an issue. Would you like to bootstrap a discussion on that particular point? I think we have enough in terms of decision making to make that happen now.

This issue was replaced by a milestone in which it is conveniently included for reference purposes and that details various work items into separate issues.

This issue was replaced by [a milestone](https://codeberg.org/forgejo/meta/milestone/3381) in which it is conveniently included for reference purposes and that details various work items into separate issues.
Contributor
Copy link

Yes, but closing it implies that all relevant things in this discussion are parsed already. Are they?

Yes, but closing it implies that all relevant things in this discussion are parsed already. Are they?

I think so but I'll let other people weigh in if they think differently.

I think so but I'll let other people weigh in if they think differently.
Contributor
Copy link

I think there is another government problem related with transparency and public avatars in teams.

I understand the need of privacy as a general value (despite still is not part of any written agreement), but I think that people with accountability responsabilities should be visible at least as an avatar.

I am refering specifically to #147; I think we are having a collision of values (transparency and privacy), because the agreements are not clear.

I think there is another government problem related with transparency and public avatars in teams. I understand the need of privacy as a general value (despite still is not part of any written agreement), but I think that people with accountability responsabilities should be visible at least as an avatar. I am refering specifically to #147; I think we are having a collision of values (transparency and privacy), because the agreements are not clear.
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
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.

Dependencies

No dependencies set.

Reference
forgejo/meta#19
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?