1) Do not make the identity of a voter casting a particular vote
public.
Don> If we make all votes secret we should require that the voting"Don" == Don Armstrong <don@debian.org> writes:
I'd also appreciate hearing more specific examples of where someone
wasn't able to vote their true preference because the vote was public.
Recently posted here in another recent thread:
This matter is extremely important for me, as soon as Debian starts
voting political/social GRs and not only technical ones.
In general I'm proposing that the chair of the TC make the decision of
who acts as secretary for that vote. The rationale there is that they
are the backup secretary for a number of constitutional functions
already.
People expecting (or maybe hoping for?) more political controversy may
feel differently; see below.
I personally would rather avoid the controversies, and the votes, that
lead to such fears.
Rationale
=========
During the vote for GR_2021_002o, several developers said they were uncomfortable voting because under the process at that time, their name
and ballot ranking would be public.
I don't actually care if our votes are readable by the general public,
so would one way of addressing the concerns of attracting abuse would be
to make the tally sheet only available to DDs behind authentication?
On 2/14/22 10:36, Philip Hands wrote:
I don't actually care if our votes are readable by the general public,
so would one way of addressing the concerns of attracting abuse would be
to make the tally sheet only available to DDs behind authentication?
I very much agree with the above.
I don't see why I would want to hide my opinion from the other DDs.
Going this path, I don't think we would need to vote on it. Please, if possible, avoid too much voting if we have other ways to fix the issue:
this is exhausting everyone.
Cheers,
Thomas Goirand (zigo)
On 2/14/22 10:36, Philip Hands wrote:
I don't actually care if our votes are readable by the general public,
so would one way of addressing the concerns of attracting abuse would be
to make the tally sheet only available to DDs behind authentication?
I very much agree with the above.
I don't see why I would want to hide my opinion from the other DDs.
On Mon, Feb 14, 2022 at 12:01:43PM +0100, Thomas Goirand wrote:
On 2/14/22 10:36, Philip Hands wrote:
I don't actually care if our votes are readable by the general public,
so would one way of addressing the concerns of attracting abuse would be >> > to make the tally sheet only available to DDs behind authentication?
I very much agree with the above.
I don't see why I would want to hide my opinion from the other DDs.
Making the ballot secret makes it possible for one to not do so if they
feel that is against their best interests, but does not stop you from
stating your opiniion publicly.
Antonio Terceiro <terceiro@debian.org> writes:
On Mon, Feb 14, 2022 at 12:01:43PM +0100, Thomas Goirand wrote:
On 2/14/22 10:36, Philip Hands wrote:
I don't actually care if our votes are readable by the general public, >> > so would one way of addressing the concerns of attracting abuse would be >> > to make the tally sheet only available to DDs behind authentication?
I very much agree with the above.
I don't see why I would want to hide my opinion from the other DDs.
Making the ballot secret makes it possible for one to not do so if they feel that is against their best interests, but does not stop you from stating your opiniion publicly.
Under what circumstances are we expecting people to think that letting
other DDs know how they voted is going to be against their interests?
If we are assuming that some DDs might start attacking people based on
the way they voted, then I'd suggest that it's more important to eject
such toxic people from Debian than it is to try to mitigate their
toxicity using measures that have negative side-effects.
"Call for experiences of <>"I don't actually care if our votes are readable by the general public, >> > so would one way of addressing the concerns of attracting abuse would be >> > to make the tally sheet only available to DDs behind authentication?
I very much agree with the above.
I don't see why I would want to hide my opinion from the other DDs.
Making the ballot secret makes it possible for one to not do so if they feel that is against their best interests, but does not stop you from stating your opiniion publicly.
Under what circumstances are we expecting people to think that letting
other DDs know how they voted is going to be against their interests?
If we are assuming that some DDs might start attacking people based onThat would indeed be good, ideally.
the way they voted, then I'd suggest that it's more important to eject
such toxic people from Debian than it is to try to mitigate their
toxicity using measures that have negative side-effects.
Antonio Terceiro <terceiro@debian.org> writes:
On Mon, Feb 14, 2022 at 12:01:43PM +0100, Thomas Goirand wrote:
On 2/14/22 10:36, Philip Hands wrote:
I don't actually care if our votes are readable by the general public, >>>> so would one way of addressing the concerns of attracting abuse would be >>>> to make the tally sheet only available to DDs behind authentication?
I very much agree with the above.
I don't see why I would want to hide my opinion from the other DDs.
Making the ballot secret makes it possible for one to not do so if they
feel that is against their best interests, but does not stop you from
stating your opiniion publicly.
Under what circumstances are we expecting people to think that letting
other DDs know how they voted is going to be against their interests?
If we are assuming that some DDs might start attacking people based on
the way they voted, then I'd suggest that it's more important to eject
such toxic people from Debian than it is to try to mitigate their
toxicity using measures that have negative side-effects.
Cheers, Phil.
Under what circumstances are we expecting people to think that letting
other DDs know how they voted is going to be against their interests?
Hi Philip (2022.02.14_13:55:45_+0000)
Under what circumstances are we expecting people to think that letting
other DDs know how they voted is going to be against their interests?
From the discussions around recent GRs, I saw that there were community members who were uncomfortable making their views on an particular
decisions public. Not because of fear of attack from a single toxic
person, but rather that there'd be many people who disagreed with their
vote.
I can imagine this if you are voting for the unpopular option, or an
option perceived as not being politically correct.
Don> We should also enable independent tabulation,[1] which you get"Don" == Don Armstrong <don@debian.org> writes:
Votes, tallies, and
results are not revealed during the voting period; after the vote
the Project Secretary lists all the votes cast.
I can imagine being fearful of that too, but what I'm interested in is whether we have any evidence of that fear being justified.
If it is actually the case that any of our votes have been followed by
people giving one-another grief over their vote, that is one thing, and
I think we need to ensure that we have mechanisms for dealing with such
an eventuality.
On the other hand, if that does not actually happen, then I'd suggest
that it's better to establish that as a well known fact than to allow
people to continue being fearful that it might be something they should expect.
2) Do not require that votes be conducted by email.
If we are assuming that some DDs might start attacking people based on
the way they voted, then I'd suggest that it's more important to eject
such toxic people from Debian than it is to try to mitigate their
toxicity using measures that have negative side-effects.
This point is right. But I am not sure Debian is robust enough, today,
to expell easily, quickly and without the victims to be disappointed to
make part of the project, someone. recent examples show how such
decisions are difficult, controversial, and while CT + DAM + DPL work on this, I think it is a long-term thought, given the original culture of
Debian and the current society state of mind.
Don> We should also enable independent tabulation,[1] which you get"Don" == Don Armstrong <don@debian.org> writes:
Don> automatically when votes are not secret. [Devotee enables this
Don> currently as well, but future non-devotee systems might not.]
I think the following text already in the constitution is sufficient to
get you independent tabulation; am I missing something?
Votes, tallies, and
results are not revealed during the voting period; after the vote
the Project Secretary lists all the votes cast.
Don> I'd also appreciate hearing more specific examples of where
Don> someone wasn't able to vote their true preference because the
Don> vote was public. I currently plan to offer (or second) an
Don> amendment to this proposal which strikes the section making all
Don> votes private and rank that higher than one which struck it,
Don> but I'm open to be convinced otherwise.
Don> My personal reasoning is that I see my role as a voting project
Don> member as more of a stewardship role where I'm trying to decide
Don> what is best for the project, rather than what is best for me
Don> personally, and I want to be seen as being a good steward for
Don> the project.
First, it looks like many participants in the discussion support your
view. Right now, I haven't seen sufficient support for this proposal
that I would propose it as a GR. If some of the people who advocated
for this during the rms GR don't step forward, I think we can avoid a
vote.
So, I think the key question is the one you raise above.
Are we acting as steward or are we acting on behalf of ourselves when we
vote in Debian?
In elections in my country, we have secret ballots.
One of the main reasons for that is that we don't want to be held to
account for our vote say either by our employers, or by a group of thugs
with baseball bats unhappy about how we voted.
That is, when we are making our own decisions as voters, we don't want
to have to explain our vote to anyone, and we don't want people to be
able to change their behavior toward us based on our vote.
If we are assuming that some DDs might start attacking people based on
the way they voted, then I'd suggest that it's more important to eject
such toxic people from Debian than it is to try to mitigate their
toxicity using measures that have negative side-effects.
On Mon, Feb 14, 2022 at 7:12 AM Jean-Philippe MENGUAL
<jpmengual@debian.org> wrote:
This point is right. But I am not sure Debian is robust enough, today,
to expell easily, quickly and without the victims to be disappointed to make part of the project, someone. recent examples show how such
decisions are difficult, controversial, and while CT + DAM + DPL work on this, I think it is a long-term thought, given the original culture of Debian and the current society state of mind.
It is hate speech, pure and simple—and should be grounds for
expulsion from the project.
Don> If we make all votes secret we should require that the voting"Don" == Don Armstrong <don@debian.org> writes:
Don> system used enables voters to validate that their vote was
Don> correctly recorded and tabulated in the final vote count.
Note that our current constitution does not require this for DPL votes.
Do you think this is important enough to require in the constitution?
I'm guessing yes since you bring it up, but I want to ask explicitly.
Don> We should also enable independent tabulation,[1] which you get
Don> automatically when votes are not secret. [Devotee enables this
Don> currently as well, but future non-devotee systems might not.]
Would you be willing to propose a merge request for these two properties
if you think it is important that we require them in the constitution?
All of them were condemned by later generations: the Salem witch hunt; >McCartyism; the cultural revolution in China; collectivisation under
Pol Pot in Cambodia; and perhaps most infamously the many attempts
over time to expel or eradicate the Jews from various territories.
The collective condition that leads to such madness is now well
understood. It is a group form of splitting and projection [1] that
affects entire societies. The phenomenon is easily recognized once you >understand it. Because of the extreme danger, Orthodox Jews teach it.
[2]
One of Germany's great insights after World War II was that all calls
for social upheaval are in themselves barbaric. The country now has
special local and federal police agencies to monitor such corrosive
speech (Verfassungsschutz).
In 1949, Arthur Miller wrote the play "The Crucible" about it. He won
a Pulitzer and many other accolades. In 1954, William Golding dealt
with similar group dynamics in the novel "The Lord of the Flies." He
received the Nobel Prize for Literature.
I am embarrassed to read the statements above on a Debian mailing
list. It is hate speech, pure and simple—and should be grounds for >expulsion from the project.
I'm likely biased because I'm in a privileged position and rarely have
to deal with concerted harassment directed specifically at me, so I
might be minimizing the real fear people have because I personally
haven't experienced it.
Perhaps the compromise position is to default to secret ballots, but
allow people to automatically unmask their preference at the appropriate time. [Totally not supported by devotee currently, but certainly
possible to enable.]
On 2/14/22 09:53, Sam Hartman wrote:
Steve certainly found feedback he got to be harassment.
I did as well.
I received some harassment (not a lot, but some) over this too. My recollection is this was coming from non-DDs.
Secret ballots are certainly not a panacea that solves all harassment,
but they may be a risk reduction measure.
"Don" == Don Armstrong <don@debian.org> writes:
Don Armstrong <don@debian.org> writes:
I'm likely biased because I'm in a privileged position and rarely have
to deal with concerted harassment directed specifically at me, so I
might be minimizing the real fear people have because I personally
haven't experienced it.
This is almost exactly my concern.
I'm not particularly worried about making all of my Debian votes public.
I've been on the Internet for a long time, have the resources to defend myself against the sorts of reactions I think are likely, and am not the
sort of person who tends to draw the most attention anyway. Maybe I'm too optimistic since things seem to be getting worse, but I'm not very worried for myself.
However, I think there's a bias implicit in that sort of analysis, and I don't want only the Debian Developers who are similarly situated to be
able to vote. If someone is more socially vulnerable than I am, I don't
want them to have to do this calculus in order to vote their conscience.
I agree with Sam's analysis that the point of Debian votes is to vote as individuals, not to vote as trustees on behalf of a constituency, and
while I too have gotten valuable understanding and course correction from seeing people I respect in the project vote differently than me, I don't think public voting is a core project value. I therefore find it hard to argue against people's perceived safety (even if it is only a perception).
Perhaps the compromise position is to default to secret ballots, but
allow people to automatically unmask their preference at the appropriate
time. [Totally not supported by devotee currently, but certainly
possible to enable.]
That's an interesting thought. My immediate reaction is that the social signaling of who reveals their votes and who doesn't is a bit complicated
and I'm not sure what effect it would have.
I think there are problematic uses of votes well beyond harassment
though.
* After this, I think the next vote is going to be about firmware.
Do we want companies like Nvidia who may have opinions about how distributions should think about freedom looking at how people vote
when they consider hiring DDs?
* Do we want ftpmaster members looking back at past votes on firmware
and DFSG interpretations before deciding someone is an appropriate
candidate?
* Would it be reasonable for the DPL to look back at votes to decide
whether to delegate to someone?
They can already do the same for mailing list communication. Do we want
to avoid this by making mailing lists non-public (subscribers only, or project members only depending on the list)?
I find the idea that someone might be forced to reveal their previously undeclared political views in order to vote particularly persuasive as a reason to have as-secret-as-possible votes on at least those subjects.
Alternatively, we could just reach a consensus not to even attempt these sorts of position statements in future, since all they do is highlight divisions.
Trying to be generous to one another and only tackle divisions when they
are of central importance to the project is a good principle, but I think there are some divisions of central importance to the project, not
everyone is going to agree on which divisions are of central importance,
and six DDs have a right under the constitution to bring a GR to a vote.
I'm also leery of getting into another situation where a vote is going to
be worrisome but we have no framework to mitigate the effects because
we've been overly hopeful that we could avoid any such vote.
Based on the way people with minority opinions are treated, you would
have to expel a lot of people.
Hi,
On Tue, Feb 15, 2022 at 12:31 PM Russ Allbery <rra@debian.org> wrote:
Trying to be generous to one another and only tackle divisions when they
are of central importance to the project is a good principle, but I think
there are some divisions of central importance to the project, not
everyone is going to agree on which divisions are of central importance,
and six DDs have a right under the constitution to bring a GR to a vote.
I'm also leery of getting into another situation where a vote is going to
be worrisome but we have no framework to mitigate the effects because
we've been overly hopeful that we could avoid any such vote.
Six DDs can force a vote, but not necessarily a decision. Would a
higher quorum help to ensure that divisive issues remain moot unless
there is broader interest?
I was wondering if we could allow expressions of disdain
(anti-seconds?), such that a second would get cancelled out for every
two DDs (or maybe a larger multiple?) that respond to a call for seconds
with an anti-second. A proposal would then need to stay at above 6
seconds for some short period after the latest anti-second landed to be considered to have a properly seconded proposal.
On Mon, 2022-02-14 at 18:47 -0700, Sam Hartman wrote:
I think there are problematic uses of votes well beyond harassment
though.
* After this, I think the next vote is going to be about firmware.
Do we want companies like Nvidia who may have opinions about how
distributions should think about freedom looking at how people vote
when they consider hiring DDs?
They can already do the same for mailing list communication. Do we want
to avoid this by making mailing lists non-public (subscribers only, or project members only depending on the list)?
I was wondering if we could allow expressions of disdain
(anti-seconds?), such that a second would get cancelled out for every
two DDs (or maybe a larger multiple?) that respond to a call for seconds
with an anti-second. A proposal would then need to stay at above 6
seconds for some short period after the latest anti-second landed to be considered to have a properly seconded proposal.
This is a vote, though, just a kind of awkward one. If we're going to
hold a vote, I think we should do it with decent software designed to
handle a vote, rather than asking some poor person to manually verify and count mailing list messages.
Also, if the declarations of disdain needed to be public, that would disenfranchise anyone that's only going to vote in secret ballots.
Ansgar <ansgar@43-1.org> writes:
On Mon, 2022-02-14 at 18:47 -0700, Sam Hartman wrote:
I think there are problematic uses of votes well beyond
harassment
though.
* After this, I think the next vote is going to be about
firmware.
Do we want companies like Nvidia who may have opinions about how distributions should think about freedom looking at how people
vote
when they consider hiring DDs?
They can already do the same for mailing list communication. Do we
want
to avoid this by making mailing lists non-public (subscribers only,
or
project members only depending on the list)?
By this token, votes in democratic countries needn't be secret,
because there are channels in which people publicly express their
opinions.
On Wed, 2022-02-16 at 13:27 +0100, Gard Spreemann wrote:
Ansgar <ansgar@43-1.org> writes:
On Mon, 2022-02-14 at 18:47 -0700, Sam Hartman wrote:
I think there are problematic uses of votes well beyond
harassment
though.
* After this, I think the next vote is going to be about
firmware.
Do we want companies like Nvidia who may have opinions about how
distributions should think about freedom looking at how people
vote
when they consider hiring DDs?
They can already do the same for mailing list communication. Do we
want
to avoid this by making mailing lists non-public (subscribers only,
or
project members only depending on the list)?
By this token, votes in democratic countries needn't be secret,
because there are channels in which people publicly express their
opinions.
And indeed most votes are not secret such as:
- votes in parliament or similar,
- votes by shareholders of publically traded companies,
- votes in general meetings of associations (maybe comparable to
the idea of GRs in Debian?),
- votes in many decision bodies.
Some votes in these groups may be secret.
Sometimes individual votes are only visible to members (say for people present at association meetings); for Debian this might be comparable
to having the tally sheet only visible to project members.
On Wed, 2022-02-16 at 13:27 +0100, Gard Spreemann wrote:
Ansgar <ansgar@43-1.org> writes:
On Mon, 2022-02-14 at 18:47 -0700, Sam Hartman wrote:
I think there are problematic uses of votes well beyond
harassment
though.
* After this, I think the next vote is going to be about
firmware.
Do we want companies like Nvidia who may have opinions about how
distributions should think about freedom looking at how people
vote
when they consider hiring DDs?
They can already do the same for mailing list communication. Do we
want
to avoid this by making mailing lists non-public (subscribers only,
or
project members only depending on the list)?
By this token, votes in democratic countries needn't be secret,
because there are channels in which people publicly express their
opinions.
And indeed most votes are not secret such as:
- votes in parliament or similar,
- votes by shareholders of publically traded companies,
- votes in general meetings of associations (maybe comparable to
the idea of GRs in Debian?),
- votes in many decision bodies.
Some votes in these groups may be secret.
Sometimes individual votes are only visible to members (say for people present at association meetings); for Debian this might be comparable
to having the tally sheet only visible to project members.
But you misunderstand the question: I asked why we insist on public
mailing lists if we are concerned about people possibly losing (or not obtaining) jobs if they make their opinion known in some archived form.
There is no requirement to have lists such as -vote@ be a public list
if people feel unsafe if their opinion is publically archived.
Philip Hands <phil@hands.com> writes:
I was wondering if we could allow expressions of disdain
(anti-seconds?), such that a second would get cancelled out for every
two DDs (or maybe a larger multiple?) that respond to a call for seconds
with an anti-second. A proposal would then need to stay at above 6
seconds for some short period after the latest anti-second landed to be
considered to have a properly seconded proposal.
This is a vote, though, just a kind of awkward one. If we're going to
hold a vote, I think we should do it with decent software designed to
handle a vote, rather than asking some poor person to manually verify and count mailing list messages.
Comments including support or alternatives are welcome.
view. Right now, I haven't seen sufficient support for this proposal
that I would propose it as a GR. If some of the people who advocated
for this during the rms GR don't step forward, I think we can avoid a
vote.
I'd also appreciate hearing more specific examples of where someone
wasn't able to vote their true preference because the vote was public. I currently plan to offer (or second) an amendment to this proposal which strikes the section making all votes private and rank that higher than
one which struck it, but I'm open to be convinced otherwise.
As you asked for a bit of a straw poll, I would support a move toward
secret ballots in all votes.
Hi Sam (2022.02.13_21:28:44_+0000)
Comments including support or alternatives are welcome.
As you asked for a bit of a straw poll, I would support a move toward
secret ballots in all votes.
I've always felt slightly awkward about having my ballots be public. Not >enough to effect or suppress my vote. But I can imagine that it is
enough to stop other people from voting their mind. I would expect that
a secret ballot would encourage a few more project members to vote and
that's a good thing.
If we trust our secret ballot mechanism enough for the DPL elections, I
trust it for other GRs.
This starts informal discussion of a proposed general resolution to
amend the constitution. I am not seeking sponsors at this time.
Comments including support or alternatives are welcome. I think this is mature enough to seek review from the secretary.
I like that a number of options have been brainstormed in the
discussion: secret ballots, ballots secret on request, ballots public on >request, ballots disclosed only to Debian Members, public ballots. I
like a GR with a range of options.
Thank you for driving this!
Rationale
=========
During the vote for GR_2021_002o, several developers said they were uncomfortable voting because under the process at that time, their name
and ballot ranking would be public.
A number of participants in the discussion believe that we would get
election results that more accurately reflect the will of the developers
if we do not make the name associated with a particular vote on the
tally sheet public.
Several people believed that the ranked votes without names attached
would still be valuable public information.
This proposal would treat all elections like DPL elections.
At the same time it relaxes the requirement that the secretary must
conduct a vote via email. There are no current plans to move away from email, although some members of the project want to explore
alternatives. If this proposal passes, adopting such an alternative
would require sufficient support in the project but would not require
another constitutional amendment.
This proposal relies on the secretary's existing power to decide how
votes are conducted. During discussion we realized that there is no mechanism to override a specific decision of the secretary, and the
language allowing the project to replace the secretary is ambiguous.
Summary of Changes
==================
1) Do not make the identity of a voter casting a particular vote
public.
2) Do not require that votes be conducted by email.
3) Clarify that the developers can replace the secretary at any time.
4) Provide a procedure for overriding the decision of the project
secretary or their delegate. Overriding the decision of what super
majority is required or overriding the determination of election
outcome requires a 3:1 majority. The chair of the technical committee
decides who conducts such votes.
"Bill" == Bill Blough <bblough@debian.org> writes:
Do we have any evidence that either thing happened?
Also, it seems to me that the problem we're considering is that toxic
people who are not really interested in Debian at all, might stumble
across Debian voting results, and then use what they find as a reason to persecute some of us on-line. Is that about right?
I have used the results of votes in the past to start conversations with people that I disagree with in some issue in order to better understand
how they came to the other view. One can generally find someone on the
other side of the argument who you already know and respect, which makes
it much harder to dismiss them as an idiot. I'd miss that in a properly secret ballot.
I don't actually care if our votes are readable by the general public,
so would one way of addressing the concerns of attracting abuse would be
to make the tally sheet only available to DDs behind authentication?
I don't actually care if our votes are readable by the general public,
so would one way of addressing the concerns of attracting abuse would be to make the tally sheet only available to DDs behind authentication?
I very much agree with the above.
I don't. When I remember how the debates were stressful and painful, and
with harasment to persons (I mean during the GR debate), I think some GHRs require secret votes. Neither I care other DDs to see my votes when it affects Debian (DPL, internal GRs, etc), or a technical debate, issue. But from the time Debian starts addressing non-technical topics, I want my vote to be secret.
For reminde, even once the vote was started, pressures went on to influence vote. So...
I support this effort, especially after the heat I've seen in the
systemd and RMS GRs, were social dynamics went far beyond the democratic curiosity of polling where people stand, and strong peer pressure was considered a valid mean to an end.
This starts informal discussion of a proposed general resolution to
amend the constitution. I am not seeking sponsors at this time.
Comments including support or alternatives are welcome. I think this is mature enough to seek review from the secretary.
On Sun, 2022-02-13 at 14:28:44 -0700, Sam Hartman wrote:
This starts informal discussion of a proposed general resolution to
amend the constitution. I am not seeking sponsors at this time.
Comments including support or alternatives are welcome. I think this is mature enough to seek review from the secretary.
Since the idea of general secret votes has started floating around
I've felt a sense of uneasiness, but I've not been able to clearly
put my finger on why. After some of the replies here, I think it's
starting to become clear.
I think the current secrecy for the DPL votes makes absolute sense,
and I think there's no contention about that one, because these are
about voting "for/against" people, which have clear and understood
social dynamics when it applies to colleagues/friends or people we do
work with etc. I think, thus, extending secrecy to any vote related
to "people" would also be equally uncontroversial.
Then, there's the secrecy for technical votes, which I think is where
the push back might be coming from. There's been mentions of mailing
lists being way more revealing than a vote in GR, and counters to that mentioning that you do not need to participate in mailing lists. Both
true. The problem I think, is that to participate in Debian in any
technical role, you most definitely need to eventually make your
opinion on technical matters public, because we operate on the open.
Be that on bug reports, on changelogs, on VCS commits, or even on
mailing lists. It also feels like closing up technical votes would go
counter to the general tenets of the project and how we operate.
And then, there's the secrecy for "political" votes. I think this
might also be problematic, depending on the subject at hand. Because
as mentioned in the thread, it might make public positions that people otherwise would not need to make so on their daily routines in Debian.
I think the RMS vote, was a mix of personal + political, which is what
made people uncomfortable with. The problem I see is that this is now
being lumped into a general direction to close everything up, which
seems excessive, TBH.
I also think the DPL votes are different to any other votes, because
the DPL has limited power, and even though a DPL can certainly disrupt
or damage the project, in the end it's bound by a time limit. Compared
to a GR where the consequences might live long, and where once settled
people do not tend to try to overturn these every subsequent year.
I've also got concerns about batching up unrelated changes, with
potentially controversial ones. And even if minor I'd prefer to see
those debundled, even at the cost of additional GRs.
I've also got concerns about batching up unrelated changes, with potentially controversial ones. And even if minor I'd prefer to see
those debundled, even at the cost of additional GRs.
If the only contentious point is the secrecy of votes, we could have an amendment that includes all the other proposed changes, minus that one.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 48:02:28 |
| Calls: | 6,710 |
| Calls today: | 3 |
| Files: | 12,243 |
| Messages: | 5,354,635 |
| Posted today: | 1 |