Codeberg/org
50
121
Fork
You've already forked org
44

Proposed constitution amendment (variant with election system in the bylaws): Use modern voting systems #1241

Open
dpk wants to merge 2 commits from dpk/org:voting-system into main
pull from: dpk/org:voting-system
merge into: Codeberg:main
Codeberg:main
Codeberg:Assembly24-Change9-PrivacyPolicy
Codeberg:readme-improvements
Codeberg:Assembly24-FullDraft
Codeberg:Assembly24-Change8-FeeRegulations
Codeberg:Assembly24-Change10-ElectionRegulations
Codeberg:Assembly24-Change6-ExplicitRegulations
Codeberg:Assembly24-Change7-WrittenCommunicationByEmail
Codeberg:Assembly24-Change5-MissingEmailExpungement
Codeberg:Assembly24-Change4-DeadlinesAndOnlineVoting
Codeberg:Assembly24-Change3-BoardPayment
Codeberg:Assembly24-Change1-BoardAndPresidium
Codeberg:Assembly24-Change2-Teams
Codeberg:tos-next
Codeberg:logo-license-exemption
Owner
Copy link

This is a variant of a proposal for which another alternative PR exists.

This version of the proposal includes the specific voting systems to be used for the assembly in the bylaws of the association.

See #1255 for a variant which fixes the voting systems in a separate regulation.


This is a proposal for an amendment to the constitution of Codeberg e.V. (Satzung) for the next member assembly.

It proposes that, in the case of elections with more than two options (excluding the possibility of explicitly abstaining), future votes will be held using a modern, fair voting system:

  1. For votes with more than one option where only one can be chosen, the Schulze method is used. This is a Condorcet-consistent voting method which uses a graph traversal algorithm to resolve paradoxes. It is widely used by FOSS/free culture projects including Debian, Ubuntu, Wikimedia Foundation ...

  2. For votes with more than one option where more than one is chosen (e.g. elections to the presidium), the single transferable vote (STV) is used. This is also used in numerous non-profit associations worldwide, and in the election of very many real political bodies like parliaments and local district councils. It is a proportional representation system in which voters can rank individuals.

For information about the problems of the ‘majority-based’ voting system currently used in such cases, see e.g. this short explanation by C. G. P. Grey. There is no perfect voting system but these are widely used, generally agreed to be ‘fair enough’, and should be familiar to association geeks and voting geeks around the world ;-)

For the avoidance of doubt about how these methods are to be implemented, the Satzung will include references to specific papers describing the exact counting algorithm to be used by Codeberg (in mathematical notation and pseudocode in the case of Schulze, and in Pascal in the case of STV (it’s a paper from 1987)).

**This is a variant of a proposal for which another alternative PR exists.** This version of the proposal includes the specific voting systems to be used for the assembly in the bylaws of the association. See #1255 for a variant which fixes the voting systems in a separate regulation. * * * This is a proposal for an amendment to the constitution of Codeberg e.V. (Satzung) for the next member assembly. It proposes that, in the case of elections with more than two options (excluding the possibility of explicitly abstaining), future votes will be held using a modern, fair voting system: 1. For votes with more than one option where only one can be chosen, the Schulze method is used. This is a Condorcet-consistent voting method which uses a graph traversal algorithm to resolve paradoxes. It is [widely used](https://en.wikipedia.org/wiki/Schulze_method#Usage) by FOSS/free culture projects including Debian, Ubuntu, Wikimedia Foundation ... 2. For votes with more than one option where more than one is chosen (e.g. elections to the presidium), the single transferable vote (STV) is used. This is also used in numerous non-profit associations worldwide, and in the election of very many real political bodies like parliaments and local district councils. It is a proportional representation system in which voters can rank individuals. For information about the problems of the ‘majority-based’ voting system currently used in such cases, see e.g. [this short explanation by C. G. P. Grey](https://www.youtube.com/watch?v=s7tWHJfhiyo). [There is no perfect voting system](https://en.wikipedia.org/wiki/Arrow%27s_impossibility_theorem) but these are widely used, generally agreed to be ‘fair enough’, and should be familiar to association geeks and voting geeks around the world ;-) For the avoidance of doubt about how these methods are to be implemented, the Satzung will include references to specific papers describing the exact counting algorithm to be used by Codeberg (in mathematical notation and pseudocode in the case of Schulze, and in Pascal in the case of STV (it’s a paper from 1987)).

I'm 100% in favor of clarifying/improving the used voting systems, but I wonder if we should set down those details in the bylaws/Satzung at all, as it's always a pain to edit Satzungen due to how the German e.V. law works?

I do appreciate/see that we'll have to touch the Satzung either way, as the current one already gives a voting system, but maybe this Satzungsänderungsantrag should just edit it to cross-reference our Wahlordnung and simultaneously set down those detailed voting system bits in that Wahlordnung.

That would at least make future updates/clarifications etc a lot easier, as it doesn't need to touch the Satzung.

I'm 100% in favor of clarifying/improving the used voting systems, but I wonder if we should set down those details in the bylaws/Satzung at all, as it's always a pain to edit Satzungen due to how the German e.V. law works? I do appreciate/see that we'll have to touch the Satzung either way, as the current one already gives a voting system, but maybe this Satzungsänderungsantrag should just edit it to cross-reference [our Wahlordnung](https://codeberg.org/Codeberg/org/src/branch/main/de/Wahlordnung.md) and simultaneously set down those detailed voting system bits in that Wahlordnung. That would at least make future updates/clarifications etc a lot easier, as it doesn't need to touch the Satzung.
Author
Owner
Copy link

Thanks for the feedback @gedankenstuecke and sorry for the late reply.

Personally I think the choice of voting system used by the association is important enough to the democratic function of the association that it should be protected by the larger majority and statutory protection needed for a Satzung change, and deliberately not subject to simple amendment like e.g. the membership fee. But if there is preference for the ‘lighter-weight’ way, I would be open to changing this proposal as you suggest.

Thanks for the feedback @gedankenstuecke and sorry for the late reply. Personally I think the choice of voting system used by the association is important enough to the democratic function of the association that it should be protected by the larger majority and statutory protection needed for a Satzung change, and deliberately not subject to simple amendment like e.g. the membership fee. But if there is preference for the ‘lighter-weight’ way, I would be open to changing this proposal as you suggest.

Thanks for getting back on this!

Wanting a higher threshold is a fair point. But I think we could say in the Satzung that the Wahlordnung can only be modified with a the same larger majority as the Satzung, if the main concern is having a higher threshold? That way we'd still avoid having to tweak the Satzung itself more frequently while keeping the same protections.

Thanks for getting back on this! Wanting a higher threshold is a fair point. But I think we could say in the Satzung that the Wahlordnung can only be modified with a the same larger majority as the Satzung, if the main concern is having a higher threshold? That way we'd still avoid having to tweak the Satzung itself more frequently while keeping the same protections.
Author
Owner
Copy link

Sorry, I feel I’m misunderstanding then. What would be the benefit of doing it that way?

A Satzungsänderung needs a two-thirds majority and the members have to be informed in advance of the assembly. We could potentially omit the requirement for members to be informed in advance, I guess, and only require the larger majority ...

Sorry, I feel I’m misunderstanding then. What would be the benefit of doing it that way? A Satzungsänderung needs a two-thirds majority and the members have to be informed in advance of the assembly. We could potentially omit the requirement for members to be informed in advance, I guess, and *only* require the larger majority ...

My understanding is that changing the Satzung is a PITA, because any changes need to be tax office (and iirc from last years discussions involve paying a lawyer too?). It's that part that I'd like to avoid for any future changes if possible. 😊

My understanding is that changing the Satzung is a PITA, because any changes need to be tax office (and iirc from last years discussions involve paying a lawyer too?). It's that part that I'd like to avoid for any future changes if possible. 😊
Owner
Copy link

For the record, the executive board wants to share the following position:

We are concerned about forcing these very specific voting systems through the bylaws. It requires implementation effort by someoneTM, and considering that we don't see a lot of contributors working on our tooling (e.g. registration server), we wonder about the plan for realizing this measure if it is accepted. Do we need to hire someone to implement it? How much would that cost? Do we have to delay votes if the system is not ready in time?

A safer and potentially more logical approach could be to implement the changes first, see if they work well for us, and then lock them down with a bylaws change or in the election regulations in the future. This would of course require to change the bylaws first to also allow the described methods in addition to the current "simple majority" votes.

We've also not discussed the exact systems in depth yet, and worry that a harder to understand voting system will lead to less transparency overall.

For the record, the executive board wants to share the following position: We are concerned about forcing these very specific voting systems through the bylaws. It requires implementation effort by someoneTM, and considering that we don't see a lot of contributors working on our tooling (e.g. registration server), we wonder about the plan for realizing this measure if it is accepted. Do we need to hire someone to implement it? How much would that cost? Do we have to delay votes if the system is not ready in time? A safer and potentially more logical approach could be to implement the changes first, see if they work well for us, and then lock them down with a bylaws change or in the election regulations in the future. This would of course require to change the bylaws first to also allow the described methods in addition to the current "simple majority" votes. We've also not discussed the exact systems in depth yet, and worry that a harder to understand voting system will lead to less transparency overall.

As an individual, I endorse the proposal of the widely used Schulze method; this would not affect "yes/no" questions.

I am deeply concerned at the timing of a response of such gravity, which was made after the Annual Assembly; close to half a year after the original proposal was made and made at a point where amending it for this year is not possible. I find this response (and timing) pattern to be repetitive and not a good signal regarding the association's ability to adjust.

Effectively, the unfortunate timing deprived us of the possibility to have sought out contributors for this year.

I encourage people voting on this to take a look at #1247 - I will be citing a comment of my own from there (#1247 (comment)).

Prolonging certain association problems because of the mere presence of other types of association problems - which we might treat as inevitable - does not help reduce the amount of certain association problems either.

Hm, if this is already turning into a problem, why can we not just scout [other contributors] for this?

In the case of the registration-server (this belongs to the other pull request), I was not able to e.g. have a contributor achieve certain milestones because of the presence of private scripts that is used to process the data sent using the registration-server form (https://join.codeberg.org).

As an individual, I endorse the proposal of the widely used Schulze method; this would not affect "yes/no" questions. I am deeply concerned at the timing of a response of such gravity, which was made after the Annual Assembly; close to half a year after the original proposal was made and made at a point where amending it for this year is not possible. I find this response (and timing) pattern to be repetitive and not a good signal regarding the association's ability to adjust. Effectively, the unfortunate timing deprived us of the possibility to have sought out contributors for this year. I encourage people voting on this to take a look at https://codeberg.org/Codeberg/org/pulls/1247 - I will be citing a comment of my own from there (https://codeberg.org/Codeberg/org/pulls/1247#issuecomment-18310508). > Prolonging certain association problems because of the mere presence of other types of association problems - which we might treat as inevitable - does not help reduce the amount of certain association problems either. > > Hm, if this is already turning into a problem, why can we not just scout [other contributors] for this? In the case of the registration-server (this belongs to the other pull request), I was not able to e.g. have a contributor achieve certain milestones because of the presence of private scripts that is used to process the data sent using the registration-server form (https://join.codeberg.org).

@n0toose wrote in #1241 (comment):

I am deeply concerned at the timing of a response of such gravity

As said during the assembly, to please participate in the linked discussions as time was limited during the assembly. This was clear ahead of time when it was (informally) agreed to have a 3 hour limit and communicated to everyone, with the amount of agenda points we can't expect a full deep dive discussion for each proposal. I've already shared my thoughts in the e.V. forum on this format, and that participating post-meeting is actually not ideal for this exact reason.

Now it basically boils down to giving opinions/positions which results in informed decision making. Which is not ideal. It beings the board's decision or a individual shouldn't matter that these opinions/positions would be shared. Although I do see that the board's position have more weight on someone's decision than that of a individual. The shared position also only come out from the practical of that the board has to realize and implement them, bylaw changes are really set-in-stone once approved.


I personally am mostly concerned with the transparency and verifying election results via these two systems. The only weight these voting systems has it that's used by parties, bodies and organizations I know by name, but nothing beyond that. Trying to familiarize by reading the given papers and articles on it, did not give me the confidence I would understand why they are more fairer and better than others and have said properties (and why they are so important). I'm not a election geek, but would still like to know how votes are counted and a result was chosen, and with my board hat on, have to possibly explain and defend the voting was fair and results were chosen correctly.

@n0toose wrote in https://codeberg.org/Codeberg/org/pulls/1241#issuecomment-18487031: > I am deeply concerned at the timing of a response of such gravity As said during the assembly, to please participate in the linked discussions as time was limited during the assembly. This was clear ahead of time when it was (informally) agreed to have a 3 hour limit and communicated to everyone, with the amount of agenda points we can't expect a full deep dive discussion for each proposal. I've already shared my thoughts in the e.V. forum on this format, and that participating post-meeting is actually not ideal for this exact reason. Now it basically boils down to giving opinions/positions which results in informed decision making. Which is not ideal. It beings the board's decision or a individual shouldn't matter that these opinions/positions would be shared. Although I do see that the board's position have more weight on someone's decision than that of a individual. The shared position also only come out from the practical of that the board has to realize and implement them, bylaw changes are really set-in-stone once approved. --- I personally am mostly concerned with the transparency and verifying election results via these two systems. The only weight these voting systems has it that's used by parties, bodies and organizations I know by name, but nothing beyond that. Trying to familiarize by reading the given papers and articles on it, did not give me the confidence I would understand why they are more fairer and better than others and have said properties (and why they are so important). I'm not a election geek, but would still like to know how votes are counted and a result was chosen, and with my board hat on, have to possibly explain and defend the voting was fair and results were chosen correctly.
Author
Owner
Copy link

@Gusted wrote in #1241 (comment):

I personally am mostly concerned with the transparency and verifying election results via these two systems. The only weight these voting systems has it that's used by parties, bodies and organizations I know by name, but nothing beyond that. Trying to familiarize by reading the given papers and articles on it, did not give me the confidence I would understand why they are more fairer and better than others and have said properties (and why they are so important). I'm not a election geek, but would still like to know how votes are counted and a result was chosen, and with my board hat on, have to possibly explain and defend the voting was fair and results were chosen correctly.

If you are interested in the exact mathematical details, here are some basic explanations (aimed at explaining why the systems are fair, not on the exact details of how to implement them).


The Schulze method, which this proposal suggests for votes where there are three or more options and exactly one of them has to be picked, is a Condorcet-based method of voting. The idea of a Condorcet method is to find the option that was most preferred by the most voters. I find it’s easier to understand these things by example, so let’s work through one.

Imagine that we are choosing one of three option, A, B, or C. We could run three head-to-head elections, A vs B, B vs C, and A vs C. However, we can also assume that each voter has a fixed order of their preferences and will probably vote according to that order, so maybe one voter might think B is the best option and vote for B against both A and C, and that A is the second best option and vote for A against C but not against B. So, instead of running three head-to-head elections, we can just run one election and ask each voter to write down their ranking. This one example voter would submit a ballot paper that looks like this:

option ranking
A 2
B 1
C 3

From each of these ballot papers we can infer how all of the voters would have voted if we had run as many head-to-head elections between two different options as there are possible combinations of options. So, from those hypothetical pairs of elections, we end up with results that might look like this:

  • In the A vs B election, A got 400 votes and B got 600 votes
  • In the B vs C election, B got 700 votes and C got 300 votes
  • In the A vs C election, A got 600 votes and C got 400 votes

So that voter above’s preferences appear to be pretty typical, because B won both of the elections it was, C lost both of the elections it was in, and A lost against B but won against C. So the voters as a whole also prefer B < A < C, so B wins the election.

Unfortunately this method has a flaw, which is that cycles are possible. Imagine that in the A vs C election, the results had been the other way around. Then we would have a situation where voters prefer B over A, B over C, but also C over A.

In my experience, cyclical preferences like this happen maybe about 10% of the time, usually over very tightly contested issues. This is a bit of a guess about how often they happen. My point is: not so rarely that it could be ignored, but also not so often that the entire idea of doing a vote this way is inherently broken, as long as there is a fair way to fix it, which is what Schulze is concerned with.

The Schulze method resolves this paradox by considering the transitive preferences of voters. In this case, B would still win with Schulze’s method even with the cycle, because the margin by which B beat C was larger (400 votes) than the margin by which C beat A (200 votes), so B is more strongly preferred than C.


The single transferable vote is a proportional election voting system, so it is for elections where more than one option is chosen in the end, like the Codeberg presidium. Unlike list-based PR systems, though, instead of relying on candidates organizing into parties and getting votes for their whole group, candidates stand as individuals and the system picks a winner that represents the interests of all voters proportionally to the number of votes cast. It does this, like Condorcet, by asking voters to rank their preferences, but then it does something rather different instead of imagining head-to-head two-way elections.

Imagine there are six candidates for Codeberg Presidium and four seats. Candidates Red, Orange, and Yellow are very much in favour of changing the colour of Codeberg’s corporate identity from blue to a warm colour like red. Candidates Blue, Indigo, and Violet like it how it is.

Assuming this is the most important issue in the Codeberg presidium election, let’s assume all the voters will probably rank their highest candidates all based on this issue. So a warmcolourist voter might vote like this:

  1. Orange
  2. Red
  3. Yellow
  4. Blue
  5. Violet
  6. Indigo

And a bluecolourist voter might vote like this:

  1. Blue
  2. Indigo
  3. Violet
  4. Yellow
  5. Red
  6. Orange

About 25% of Codeberg’s members want the colours changed to be warmer, so the first ballot paper is roughly typical for about 25% of voters, and the second ballot paper is typical for about 75% of voters. The result if roughly this happened would thus be that Blue, Indigo, Violet, and Orange would be elected.

As for how the calculation actually works, this is best explained by a video (or by one of the many, many other sources out there). STV is very widely used indeed and there’s a lot of information out there on how it works and why it’s fair.


As for how we can make sure the result is transparent and verifiable, the obvious solution is to release the exact ballot papers with rankings as a data file after the election. The Satzung proposal exactly specifies which algorithms are to be used and how they are to be implemented, so a dedicated Codeberg user could take it upon themself to verify that the result we announced is correct for those ballot papers.

We should also make the step-by-step details of the count public too. For Schulze, you can see how Debian does that nicely here demonstrating how each pairing beat every other pairing. For STV, this means showing the result after each stage, who has been elected and who eliminated, and what the new vote tallies are after each elimination or successful election.

@Gusted wrote in https://codeberg.org/Codeberg/org/pulls/1241#issuecomment-18489710: > I personally am mostly concerned with the transparency and verifying election results via these two systems. The only weight these voting systems has it that's used by parties, bodies and organizations I know by name, but nothing beyond that. Trying to familiarize by reading the given papers and articles on it, did not give me the confidence I would understand why they are more fairer and better than others and have said properties (and why they are so important). I'm not a election geek, but would still like to know how votes are counted and a result was chosen, and with my board hat on, have to possibly explain and defend the voting was fair and results were chosen correctly. If you are interested in the exact mathematical details, here are some basic explanations (aimed at explaining why the systems are fair, not on the exact details of how to implement them). * * * The Schulze method, which this proposal suggests for votes where there are three or more options and exactly one of them has to be picked, is a Condorcet-based method of voting. The idea of a Condorcet method is to find the option that was most preferred by the most voters. I find it’s easier to understand these things by example, so let’s work through one. Imagine that we are choosing one of three option, A, B, or C. We could run three head-to-head elections, A vs B, B vs C, and A vs C. However, we can also assume that each voter has a fixed order of their preferences and will probably vote according to that order, so maybe one voter might think B is the best option and vote for B against both A and C, and that A is the second best option and vote for A against C but not against B. So, instead of running three head-to-head elections, we can just run one election and ask each voter to write down their ranking. This one example voter would submit a ballot paper that looks like this: | option | ranking | |---------|---------| | A | 2 | | B | 1 | | C | 3 | From each of these ballot papers we can infer how *all* of the voters *would* have voted if we had run as many head-to-head elections between two different options as there are possible combinations of options. So, from those hypothetical pairs of elections, we end up with results that might look like this: - In the A vs B election, A got 400 votes and B got 600 votes - In the B vs C election, B got 700 votes and C got 300 votes - In the A vs C election, A got 600 votes and C got 400 votes So that voter above’s preferences appear to be pretty typical, because B won both of the elections it was, C lost both of the elections it was in, and A lost against B but won against C. So the voters as a whole also prefer B < A < C, so B wins the election. Unfortunately this method has a flaw, which is that cycles are possible. Imagine that in the A vs C election, the results had been the other way around. Then we would have a situation where voters prefer B over A, B over C, but also C over A. In my experience, cyclical preferences like this happen maybe about 10% of the time, usually over very tightly contested issues. This is a bit of a guess about how often they happen. My point is: not so rarely that it could be ignored, but also not so often that the entire idea of doing a vote this way is inherently broken, as long as there is a fair way to fix it, which is what Schulze is concerned with. The Schulze method resolves this paradox by considering the transitive preferences of voters. In this case, B would still win with Schulze’s method even with the cycle, because the margin by which B beat C was larger (400 votes) than the margin by which C beat A (200 votes), so B is more strongly preferred than C. * * * The single transferable vote is a proportional election voting system, so it is for elections where more than one option is chosen in the end, like the Codeberg presidium. Unlike list-based PR systems, though, instead of relying on candidates organizing into parties and getting votes for their whole group, candidates stand as individuals and the system picks a winner that represents the interests of all voters proportionally to the number of votes cast. It does this, like Condorcet, by asking voters to rank their preferences, but then it does something rather different instead of imagining head-to-head two-way elections. Imagine there are six candidates for Codeberg Presidium and four seats. Candidates Red, Orange, and Yellow are very much in favour of changing the colour of Codeberg’s corporate identity from blue to a warm colour like red. Candidates Blue, Indigo, and Violet like it how it is. Assuming this is the most important issue in the Codeberg presidium election, let’s assume all the voters will probably rank their highest candidates all based on this issue. So a warmcolourist voter might vote like this: 1. Orange 2. Red 3. Yellow 4. Blue 5. Violet 6. Indigo And a bluecolourist voter might vote like this: 1. Blue 2. Indigo 3. Violet 4. Yellow 5. Red 6. Orange About 25% of Codeberg’s members want the colours changed to be warmer, so the first ballot paper is roughly typical for about 25% of voters, and the second ballot paper is typical for about 75% of voters. The result if roughly this happened would thus be that Blue, Indigo, Violet, and Orange would be elected. As for how the calculation actually works, this is [best explained by a video](https://www.youtube.com/watch?v=l8XOZJkozfI) (or by one of the many, many other sources out there). STV is very widely used indeed and there’s a lot of information out there on how it works and why it’s fair. * * * As for how we can make sure the result is transparent and verifiable, the obvious solution is to release the exact ballot papers with rankings as a data file after the election. The Satzung proposal exactly specifies which algorithms are to be used and how they are to be implemented, so a dedicated Codeberg user could take it upon themself to verify that the result we announced is correct for those ballot papers. We should also make the step-by-step details of the count public too. For Schulze, you can see how Debian does that nicely [here](https://www.debian.org/vote/2025/vote_001) demonstrating how each pairing beat every other pairing. For STV, this means showing the result after each stage, who has been elected and who eliminated, and what the new vote tallies are after each elimination or successful election.

Although I do see that the board's position have more weight on someone's decision than that of a individual.

I mean, I'd hope so, if it starts with "the executive board wants to share", there's some authority being asserted on your behalf there to make a certain argument.

This was clear ahead of time when it was (informally) agreed to have a 3 hour limit and communicated to everyone, with the amount of agenda points we can't expect a full deep dive discussion for each proposal.

As said during the assembly, to please participate in the linked discussions as time was limited during the assembly.

The shared position also only come out from the practical of that the board has to realize and implement them, bylaw changes are really set-in-stone once approved.

I understand with the questions about the substance, but I'm concerned about the comms and the approach.

The timing and the formalities were clear; thankfully, many of us submitted lots of proposals with a lot of time ahead, specifically to avoid surprising people and being surprised ourselves, while reducing the overall discussion time. This effort was done to avoid a situation that might jeopardize a proposal for another year. In my other (linked) proposal's case, I sympathize with the notion that a new thought simply popped up out of nowhere. In this very case, I can't say I understand the timing; at least not without compromises or awareness of said timing being established.

The Bylaw change still isn't set-in-stone, but the "seriousness" of the proposal was IMHO established when the PR was made; many months before. Or, well, at least when the email with the proposal submission was sent. Or, well, when it was talked about during the Annual Assembly, which would have been a good time to say something like one of the following:

  • "you should make the proposal 'come to force' once the technical capabilities are in place"
  • "include both voting systems"
  • "let's agree we want to do this and we want to ratify this through a circular vote sent later in the year once there is a visible implementation by someone" (or something like that)
  • "can you/we help you try and find a contributor for this?" instead of "we'd have to find a contributor for this"

... even by bringing up such a concern in the chat (like for the "election regulation"). Otherwise, by bringing up new problems at the wrong time (that'd take an indeterminate time to resolve -> no proposed pathway, just "needs") instead of contributing to solutions (even if it has to be something as radical as "let's do another annual assembly over this") on the table, well-meaning contributors do feel left hanging, and useful proposals die. (e.g. #1208)

> Although I do see that the board's position have more weight on someone's decision than that of a individual. I mean, I'd hope so, if it starts with "the executive board wants to share", there's some authority being asserted on your behalf there to make a certain argument. > This was clear ahead of time when it was (informally) agreed to have a 3 hour limit and communicated to everyone, with the amount of agenda points we can't expect a full deep dive discussion for each proposal. > As said during the assembly, to please participate in the linked discussions as time was limited during the assembly. > The shared position also only come out from the practical of that the board has to realize and implement them, bylaw changes are really set-in-stone once approved. I understand with the questions about the substance, but I'm concerned about the comms and the approach. The timing and the formalities were clear; thankfully, many of us submitted lots of proposals with a lot of time ahead, specifically to avoid surprising people and being surprised ourselves, while reducing the overall discussion time. This effort was done to avoid a situation that might jeopardize a proposal for another year. In my other (linked) proposal's case, I sympathize with the notion that a new thought simply popped up out of nowhere. In this very case, I can't say I understand the timing; at least not without compromises or awareness of said timing being established. The Bylaw change still isn't set-in-stone, but the "seriousness" of the proposal was IMHO established when the PR was made; many months before. Or, well, at least when the email with the proposal submission was sent. Or, well, when it was talked about during the Annual Assembly, which would have been a good time to say something like one of the following: - "you should make the proposal 'come to force' once the technical capabilities are in place" - "include both voting systems" - "let's agree we want to do this and we want to ratify this through a circular vote sent later in the year once there is a visible implementation by someone" (or something like that) - "can you/we help you try and find a contributor for this?" instead of "we'd have to find a contributor for this" ... even by bringing up such a concern in the chat (like for the "election regulation"). Otherwise, by bringing up new problems at the wrong time (that'd take an indeterminate time to resolve -> no proposed pathway, just "needs") instead of contributing to solutions (even if it has to be something as radical as "let's do another annual assembly over this") on the table, well-meaning contributors do feel left hanging, and useful proposals die. (e.g. https://codeberg.org/Codeberg/org/pulls/1208)
Contributor
Copy link

For the record, the executive board wants to share the following position:

For the record, a member wants to share the following position:

I think it reflects badly on the board that it - which I assume is the organizer of the annual assembly - couldn't voice that position during the assembly. This then starts to feel like retroactively trying to change things after being caught off-guard, and a board caught off-guard by such proposals is concerning to me.

We are concerned about forcing these very specific voting systems through the bylaws. It requires implementation effort by someoneTM, and considering that we don't see a lot of contributors working on our tooling (e.g. registration server), we wonder about the plan for realizing this measure if it is accepted. Do we need to hire someone to implement it? How much would that cost? Do we have to delay votes if the system is not ready in time?

That's something that the board has to figure out, and not something that should be a concern regarding the vote. In the PR for the proposal regarding the fee-waiver, someone brought up that a better solution is to have Codeberg actively recruit people, so maybe that's a way!

Either way, if these concerns were important, they should have been brought up during the annual assembly (or hey, even earlier and perhaps convincing the person who advanced the proposal to not submit it just yet). Since they weren't voiced during the annual assembly, I think it reflects very badly on the board that it tries to take an official position just now, and makes it seem less legitimate in my eyes.

> For the record, the executive board wants to share the following position: For the record, a member wants to share the following position: I think it reflects badly on the board that it - which I assume is the organizer of the annual assembly - couldn't voice that position during the assembly. This then starts to feel like retroactively trying to change things after being caught off-guard, and a board caught off-guard by such proposals is concerning to me. > We are concerned about forcing these very specific voting systems through the bylaws. It requires implementation effort by someoneTM, and considering that we don't see a lot of contributors working on our tooling (e.g. registration server), we wonder about the plan for realizing this measure if it is accepted. Do we need to hire someone to implement it? How much would that cost? Do we have to delay votes if the system is not ready in time? That's something that the board has to figure out, and not something that should be a concern regarding the vote. In the PR for the proposal regarding the fee-waiver, someone brought up that a better solution is to have Codeberg actively recruit people, so maybe that's a way! Either way, if these concerns were important, they should have been brought up during the annual assembly (or hey, even earlier and perhaps convincing the person who advanced the proposal to not submit it just yet). Since they weren't voiced during the annual assembly, I think it reflects very badly on the board that it tries to take an official position just now, and makes it seem less legitimate in my eyes.
Contributor
Copy link

While I went with the assuption that creating each individual poll is taking a bit of time (there were at times 30 minutes to 90 minutes of waiting time before a new one showed up), it's been nearly 2 days since the last poll went up. This proposal wasn't put up to a vote, and the extended delay is making it hard to believe it's not intentional.

Why is this proposal not put up to a vote yet?

While I went with the assuption that creating each individual poll is taking a bit of time (there were at times 30 minutes to 90 minutes of waiting time before a new one showed up), it's been nearly 2 days since the last poll went up. This proposal wasn't put up to a vote, and the extended delay is making it hard to believe it's not intentional. Why is this proposal not put up to a vote yet?
You can see the forum thread here: https://forum.codeberg.org/d/165-when-are-we-sending-out-the-votes/4 🙂
dpk changed title from (削除) Proposed constitution amendment: Use modern voting systems (削除ここまで) to Proposed constitution amendment (variant with election system in the bylaws): Use modern voting systems 2026年07月11日 19:55:37 +02:00
This pull request doesn't have enough approvals yet. 0 of 1 approvals granted.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u voting-system:dpk-voting-system
git switch dpk-voting-system
Sign in to join this conversation.
No reviewers
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
6 participants
Notifications
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
Codeberg/org!1241
Reference in a new issue
Codeberg/org
No description provided.
Delete branch "dpk/org:voting-system"

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?