Democratic issue: rushing decisions

[Thierry]

Hi,

several developers asked for delays, to respect people with a busy
schedule, to allow a constructive debate, to explore all possibilities,
to move away from the noise and confusion related to a minor event
[1,2,3,4,5,6].

Democracy is not a race, i wish such a simple and reasonable request to
be respected.

Ciao,
Thierry

[1] John : "I don't see a reason to rush a vote"
https://groups.google.com/g/sage-devel/c/ayOL8_bzOfk/m/q5V9ov5FAAAJ

[2] Jan : "I don't think the move is so urgent though"
https://groups.google.com/g/sage-devel/c/ayOL8_bzOfk/m/0Lk5pzdjBwAJ

[3] Vincent : "For me the discussion in this thread is very premature"
https://groups.google.com/g/sage-devel/c/ayOL8_bzOfk/m/ZTXx_speBwAJ

[4] Sébastien : "The urgency of short term issues does not imply the
urgency of long term issues"
https://groups.google.com/g/sage-devel/c/ayOL8_bzOfk/m/B19uBWUJCAAJ

[5] Travis : "First off, we need to slow down significantly as we do not
have an general clear consensus about doing this move."
https://groups.google.com/g/sage-devel/c/ayOL8_bzOfk/m/E3_sU2Y6CAAJ

[6] Thierry : "one month break is a bare minimum."
https://groups.google.com/g/sage-devel/c/ayOL8_bzOfk/m/STo_AT9qFgAJ

[Matthias Koeppe]

Hi Thierry, 

It was to be expected that you'd send a message trying to question the legitimacy of the poll; 

I was only wondering whether it would arrive before or after the voting deadline.

It is the opposite of constructive.

[William Stein]

> several developers asked for delays

The only governance mechanism we have for decision making in the Sage
project currently is a vote of the entire dev community. Thus there
is no way to consider your request to delay voting aside from having
even more voting.

-- William

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/20221005101108.GA2005%40metelu.net.



--
William (http://wstein.org)

[Matthias Koeppe]

On Wednesday, October 5, 2022 at 3:11:12 AM UTC-7 Thierry (sage-googlesucks@xxx) wrote:

several developers asked for delays [...] 
[1,2,3,4,5,6].

This is a misrepresentation of most of the 6 cited messages. I'll just point out one specifically:

 

[3] Vincent : "For me the discussion in this thread is very premature"
https://groups.google.com/g/sage-devel/c/ayOL8_bzOfk/m/ZTXx_speBwAJ

This message from Vincent dates Sep 10, which *prompted* our efforts to write the detailed 

transition guide, work out many details etc. over the following week.

[David Roe]

I will also note that the final vote in favor of moving to github was 46 to 8 in favor.  Another few weeks of discussion, on top of the substantial amount of time spent over the last few months (in fact, over the last decade), is unlikely to have changed the outcome.

David

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/6ffb834f-3300-43c6-be46-db35ec4000a6n%40googlegroups.com.

[Vincent Delecroix]

Dear all,

I do not interpret Thierry message as an attempt to change the issue
of the vote. Most of the answers focused on this particular point and
hence look completely off topic to me. More dramatically they are also
very rude in that they try to discredit what Thierry attempted to
share. I also felt a lot of violence during the discussion that
preceded the vote and it does continue right now. The problem is about
the form and not about the issue of the decision.

Best,
Vincent

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAChs6_nBRxsymmF4t8aL2ebpyNjU7WfS7F3%3DBTCTjco%2B815rQA%40mail.gmail.com.

[Matthias Koeppe]

On Wednesday, October 5, 2022 at 11:44:37 AM UTC-7 vdelecroix wrote:

I do not interpret Thierry message as an attempt to change the issue
of the vote.

It's probably better if Thierry could clarify that.

[Matthias Koeppe]

I'm guessing that this must be a language barrier at work here, 

but these accusations of using "violence" 

(first occurrence, https://cfce091fecee537040d612098a22852d9f083c36--sagemath-tobias.netlify.app/developer/index.html#welcome-to-the-sage-developer-s-guide)

are by far the most offensive thing that happened both in the original thread and in the current thread.

On Wednesday, October 5, 2022 at 11:44:37 AM UTC-7 vdelecroix wrote:

[Matthias Koeppe]

Sorry, bad link, I meant to paste this link: 

https://groups.google.com/g/sage-devel/c/ayOL8_bzOfk/m/5jotDDgyBwAJ

[Dima Pasechnik]

I must have been what Dutch would call "direct", English "undiplomatic" and French "violent", I guess. 

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/89395afb-19cf-4013-8fb0-befdf4643a5cn%40googlegroups.com.

[John H Palmieri]

The main response I saw to the requests for a slower process was from David Roe, saying, "Finally, since we're just voting on trac vs github I don't think there's a need to draw out the discussion until October 1, and several people (William and Dima) have made arguments for making a decision more quickly." I find this rather dismissive of the views of those who requested a more deliberate process. It would be good to have a procedure for determining timing for votes, something other than one person just making a decision.

As a starting point:

1. Anyone can call for a vote, and the vote should last at least a week: it is not reasonable to ask for votes more quickly than that, barring an emergency that demands very fast action. We call for votes all the time, e.g. recent decisions about formatting options for Sage documentation, and there is no reason to make the overall procedure more complicated.

2. Anyone can then request a delay or an extension of the vote. The default response should be to accept the delay/extension: "yes, the vote will now end on ...". If people believe that the delay is unreasonable ("we need to delay this vote by 25 years") or if they have other reasons to object, then we can hold a one-week vote, no delays allowed, to decide whether to accept the delay or not.

The second point is flawed: what to do if there are multiple requests to delay? Maybe see if the people making the requests can come to a consensus about the time. If not, then vote on the shortest proposed delay? The longest one? The average? (We have a reasonably healthy community, but all the same, I don't want to create a rule that can be abused: one person asks for a ridiculous delay, then we hold a one-week vote that fails, then another person, or even the same person, asks for another ridiculous delay, etc.)

Alternatively, we have a steering committee that steps in to make decisions, for example about the timing of votes, when there is disagreement.

Other options?

--

John

On Wednesday, October 5, 2022 at 3:11:12 AM UTC-7 Thierry (sage-googlesucks@xxx) wrote:

[William Stein]

On Wed, Oct 5, 2022 at 8:09 PM John H Palmieri <jhpalm...@gmail.com> wrote:
>
> The main response I saw to the requests for a slower process was from David Roe, saying, "Finally, since we're just voting on trac vs github I don't think there's a need to draw out the discussion until October 1, and several people (William and Dima) have made arguments for making a decision more quickly." I find this rather dismissive of the views of those who requested a more deliberate process. It would be good to have a procedure for determining timing for votes, something other than one person just making a decision.
>
> As a starting point:
>
> 1. Anyone can call for a vote, and the vote should last at least a week: it is not reasonable to ask for votes more quickly than that, barring an emergency that demands very fast action. We call for votes all the time, e.g. recent decisions about formatting options for Sage documentation, and there is no reason to make the overall procedure more complicated.
> 2. Anyone can then request a delay or an extension of the vote. The default response should be to accept the delay/extension: "yes, the vote will now end on ...". If people believe that the delay is unreasonable ("we need to delay this vote by 25 years") or if they have other reasons to object, then we can hold a one-week vote, no delays allowed, to decide whether to accept the delay or not.
>
> The second point is flawed: what to do if there are multiple requests to delay? Maybe see if the people making the requests can come to a consensus about the time. If not, then vote on the shortest proposed delay? The longest one? The average? (We have a reasonably healthy community, but all the same, I don't want to create a rule that can be abused: one person asks for a ridiculous delay, then we hold a one-week vote that fails, then another person, or even the same person, asks for another ridiculous delay, etc.)
>
> Alternatively, we have a steering committee that steps in to make decisions, for example about the timing of votes, when there is disagreement.
>
> Other options?

What happens in an academic department (e.g., UW)? For example, what
if there is an important department vote about to happen that is
brought to the faculty by a committee, and a faculty member states at
the faculty meeting: "we should delay this vote for 2 weeks to respect
people with a busy schedule, to allow a constructive debate, and to
explore all possibilities". Is there a procedure for delaying votes
in faculty meetings?

I'm just asking because bylaws tend to spell out in detail the answers
to questions like this, and it's nice to have a concrete example.

I tried searching for examples of delaying votes in US politics, and
in Summer 2020, Trump tried very hard to delay the US presidential
election:

https://www.google.com/search?q=trump+delay+election

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/66bd89d6-7cbc-4262-9c22-66d8c238eb35n%40googlegroups.com.



--
William (http://wstein.org)

[Kwankyu Lee]

A suggestion for votes for sage development process:

1.  Anyone can call for a vote for a relevant issue for sage development.

2.  A vote must be preceded by a discussion on the issue on sage-devel, where the date and the duration of the vote is determined. A vote lasts at least a week. 

3.  If a dispute about the date or the duration of the vote arises, we have another vote for the date or the duration among the suggested candidates. This vote for vote is called for only once, immediately, and lasts for a week.

An exemplary format of a vote is https://groups.google.com/g/sage-devel/c/7h5JoRgHpxY

Will we have a vote for this? :) Other suggestion? 

  

[Dima Pasechnik]

I don't think it is feasible to design a system to delay voting. If we don't limit the delaying powers of participants, effectively every vote can be put off indefinitely. 

If we limit such powers, e.g. allowing just one delaying request per year per person, then another vote can be called on a slightly different question, effectively overruling the delaying request.

There is also a question of deciding whether the delaying request is reasonable. The only possibility seems to be to give no reason whatsoever, but this is then effectively a veto power, albeit a temporary one...

Dima

--

You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/08d11497-7595-4f11-be10-41640781abfan%40googlegroups.com.

[kcrisman]

several developers asked for delays, to respect people with a busy
schedule, 

[6] Thierry : "one month break is a bare minimum."
https://groups.google.com/g/sage-devel/c/ayOL8_bzOfk/m/STo_AT9qFgAJ

In general I am very sympathetic to having "all deliberate speed" on big decisions like this, and John has brought some good relevant points to the discussion.  The question of exactly what we were voting on does seem to have been not voted on, precisely, but we don't need infinite regress, and the consensus did seem to be that these two options were the only ones that were feasible for the people who were actually currently volunteering effort, and that they did not rule out work on the other possible options for when people interested in those would be able to also give time and energy to that potential migration/mirroring.

Moreover, it has in fact been over three weeks since this message was sent, and the vote only closed yesterday.  A month does seem like a long time to wait on an yes/no online vote, particularly when it is neither the Northern nor Southern Hemisphere summer breaks, and given that quite a bit of explicit fleshing out happened on the proposal.  After all, at different times each one of us may have a "busy schedule".  The implied presumption seems to be that only things like conferences and beginnings to academic years, as opposed to far heavier teaching loads and number of children than most people on this list are likely to have, count for "busy", though I hope that was not actually the intention.  Nonetheless, probably *everyone* on this list has a busy schedule, which is why it is good that the vote was only for one specific thing, and it was not a vote that keeps other options off the table in the long (or even fairly near) term.  Even for me, this seems to have been a decent compromise between all these conflicting things.

(And for the record, I chose to abstain since I have not been able to actively contribute code in the last few years because of ... a busy schedule.)

[kcrisman]

If we limit such powers, e.g. allowing just one delaying request per year per person, then another vote can be called on a slightly different question, effectively overruling the delaying request.

Whether two requests are two similar is the sort of thing a parliamentarian decides in (US-based, at least) committee procedures, e.g. Robert's Rules or Keesey, so it is plausible to have in some contexts.  I don't think we want to go that route in this forum, of course. 

[John H Palmieri]

Hi William,

There is nothing in our department's bylaws to provide for a delay of voting, but we have a chair and we have an executive committee, and the hope is that they care not only about the particular issue at hand, but also about the atmosphere in the department. So if someone asked for a delay, probably the executive committee would consider it and make a decision. That would not likely result in a vote on whether to delay, but just a decision to delay the vote, and probably to schedule some meetings for discussion.

  John

[William Stein]

On Thu, Oct 6, 2022 at 8:45 AM John H Palmieri <jhpalm...@gmail.com> wrote:
> Hi William,
> There is nothing in our department's bylaws to provide for a delay of voting, but we have a chair and we have an executive committee, and the hope is that they care not only about the particular issue at hand, but also about the atmosphere in the department. So if someone asked for a delay, probably the executive committee would consider it and make a decision. That would not likely result in a vote on whether to delay, but just a decision to delay the vote, and probably to schedule some meetings for discussion.
> John

Thanks! So it's basically this model that you already described:

"Alternatively, we have a steering committee that steps in to make
decisions, for example about the timing of votes, when there is

disagreement." Having an elected steering committee is common in
other software projects I pay attention to (e.g., Python and Jupyter).

-- William

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/bf5f5f37-72b1-4c2f-9289-a7ff61d0aae2n%40googlegroups.com.



--
William (http://wstein.org)

[Dima Pasechnik]

I hope we don't introduce something akin to the US Senate filibuster :-)

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CACLE5GCAjKp9hXNMf2YJXZ4uq5pG1Q-s1xvpj_aix0WJ12hkng%40mail.gmail.com.

[Jonathan Thornburg]

On Thu, Oct 6, 2022 at 8:45 AM John H Palmieri <jhpalm...@gmail.com> wrote:
> There is nothing in our department's bylaws to provide for a delay of
> voting, but we have a chair and we have an executive committee, and the
> hope is that they care not only about the particular issue at hand, but
> also about the atmosphere in the department. So if someone asked for a
> delay, probably the executive committee would consider it and make a
> decision. That would not likely result in a vote on whether to delay, but
> just a decision to delay the vote, and probably to schedule some meetings
> for discussion.

On Thu, Oct 06, 2022 at 09:25:26AM -0700, William Stein wrote:
> Thanks! So it's basically this model that you already described:
> "Alternatively, we have a steering committee that steps in to make
> decisions, for example about the timing of votes, when there is
> disagreement." Having an elected steering committee is common in
> other software projects I pay attention to (e.g., Python and Jupyter).

As another data point, in section 12.8 of his book "The Design and
Evolution of C++", Bjarne Stroustrup describes an invocation of a
"delay a vote to the next meeting" rule in the ANSI/ISO C++ standards
committee (which at the time typically met about 3 times per year):

[[a proposal for extending the C++ language]] was presented at the
standards meeting in Seattle in July 1990. There appeared to be a
massive majority for making this the first non-mandated extension
to C++. At that point, Beth Crockett from Apple stopped the committee
dead in its tracks by invoking what is known as the "two week rule:"
Any member can postpone voting on a proposal that has not been in
the hands of the members at least two weeks before the meeting until
the following meeting. This rule protects people against being rushed
into things they don't understand and ensures that there will always
be time to consult with colleagues.

As you might imagine, Beth didn't gain instant popularity by that
veto. However, her caution was well founded, and she saved us from
making a bad mistake. Thanks! As we reexamined the problem after
the meeting, Doug McIlroy [[found a better solution]]

--
-- "Jonathan Thornburg [remove -color to reply]" <dr.j.th...@gmail-pink.com>
currently on the west coast of Canada
"Why would we install sewers in London? Everyone keeps getting cholera
again and again so there's obviously no reason to install sewers. We
just need to get used to this as the new normal."
-- 2022-Jul-25 tweet by "Neoliberal John Snow"

[Dima Pasechnik]

In our case, the delay was requested by an individual who for months ignores repeated requests to provide a backup of our old wiki (which he hosts in his academic department, without anyone else having access to the host). One of the reasons for delay given was that he was upset that I "violently" (I guess in Frenchish this means "bluntly") pointed this out on this very forum, as an example of dangers of a small bus factor.

And in our case the voting was allowed over a long period of time.

Dima

--
-- "Jonathan Thornburg [remove -color to reply]" <dr.j.th...@gmail-pink.com>
   currently on the west coast of Canada
   "Why would we install sewers in London?  Everyone keeps getting cholera
    again and again so there's obviously no reason to install sewers.  We
    just need to get used to this as the new normal."
                            -- 2022-Jul-25 tweet by "Neoliberal John Snow"

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/Yz8qqM4YuOVtYNJI%40iron.bkis-orchard.net.

[John H Palmieri]

Dima, presumably you're not talking about me, although I proposed that "we start a vote around October 1".

Anyway, the point of having a policy is so that we don't have to concern ourselves with the motives of the people requesting the delay or anything else: we would just handle the request as our policy dictates.

[Matthias Koeppe]

On Thursday, October 6, 2022 at 3:05:38 PM UTC-7 John H Palmieri wrote:

Anyway, the point of having a policy is so that we don't have to concern ourselves with the motives of the people requesting the delay or anything else: we would just handle the request as our policy dictates.

+1.

 

[Kwankyu Lee]

On Friday, October 7, 2022 at 7:05:38 AM UTC+9 John H Palmieri wrote:

Dima, presumably you're not talking about me, although I proposed that "we start a vote around October 1".

 

I guess he means: https://trac.sagemath.org/ticket/33725#comment:26

[Dima Pasechnik]

yes, that's exactly what I meant.

Dima

>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/be5e2daa-6e2d-4437-bc3a-a8bf38f5a5c6n%40googlegroups.com.

[John H Palmieri]

I apologize for being indirect. I was responding to Dima's sentence, "... the delay was requested by an individual ..." which implies that there was just one person requesting the delay. I was pointing out, apparently too indirectly, that more than one person had requested a delay, and perhaps not everyone who requested a delay was guilty, in Dima's view, of some transgression.

In short: Dima, cut it out with the straw men ("straw man: an intentionally misrepresented proposition that is set up because it is easier to defeat than an opponent's real argument").

[Tobias Diez]

I just had another look at the voting thread, where most votes were voiced in the first two days, and the almost-slient discussion thread, where mostly a few practical aspects of the migrations were discussed. From this, I don't get the impression that the most voters felt they needed more time to think or discuss their decision.

In general, I would keep the voting system simple. The migration to github was one particular vote, but for example the voting on the doc styles was held without much of a prior discussion and on a shorter deadline.

So maybe something simple as the following?
"Small votes:" Have to have a github issue that is at least one week old, don't require a discussion on the mailing list and the voting period cannot be shorter than 4 days.
"Big votes": Require a discussion thread on the mailing list that is at least one week old and the voting period cannot be shorter than 1.5 weeks.

Upon the public request of a single member of the mailing list, every "small vote" can be upgraded to a "big vote". In this case, all previously handed-in votes are invalid and a discussion thread has to be opened.

[John H Palmieri]

Maybe more to the point, the thread was going in the direction of a general policy discussion about how to conduct votes and how to handle requests for delays. Dima interrupted, unprompted as far as I can see, by bringing back up the particular recent case along with comments about one particular person who had advocated for a delay. We should be able to discuss general policy issues without this kind of derailing.

[John H Palmieri]

On Friday, October 7, 2022 at 9:48:29 AM UTC-7 tobias...@gmail.com wrote:

I just had another look at the voting thread, where most votes were voiced in the first two days, and the almost-slient discussion thread, where mostly a few practical aspects of the migrations were discussed. From this, I don't get the impression that the most voters felt they needed more time to think or discuss their decision.

Discussions about the timing of the vote were mainly in the thread "incremental migration to github?", not the discussion thread or the vote thread.Also, I'm not sure it matters what "most voters" felt. If a few people felt the need to delay, that should have an effect.

[Matthias Koeppe]

On Friday, October 7, 2022 at 9:55:09 AM UTC-7 John H Palmieri wrote:

On Friday, October 7, 2022 at 9:48:29 AM UTC-7 tobias...@gmail.com wrote:

I just had another look at the voting thread, where most votes were voiced in the first two days, and the almost-slient discussion thread, where mostly a few practical aspects of the migrations were discussed. From this, I don't get the impression that the most voters felt they needed more time to think or discuss their decision.

Discussions about the timing of the vote were mainly in the thread "incremental migration to github?", not the discussion thread or the vote thread.Also, I'm not sure it matters what "most voters" felt. If a few people felt the need to delay, that should have an effect.

In general I agree with you, but for what it's worth, I certainly thought that David had reached a thoughtful compromise regarding the voting timeline in his message of Sep 19. 

John, your proposed Oct 1 deadline (from your message on Sep 16) had seemed to be conditional on interest in including GitLab in the vote, but there seemed to be little interest in that on the list. 

Sebastien's earlier request in his message of Sep 12 lacked concreteness (he asked that "the discussion on the long term issues should be done when the urgent short term issues are dealt with").

All earlier requests for delays had asked either (a) for work to be done as a prerequisite for a discussion (which had been completed by Sep 12 or so), or (b) for work to stop (which had been retracted after a clarification of facts).

No discussion of timing happened on the list after David's Sep 19 message and before the start of the vote (Sep 21); and there were also no requests for extensions of the deadline when the vote was open.

(I have compiled a timeline of the relevant messages on the list that I'll be happy to share with anyone interested)

Matthias

[Matthias Koeppe]

On Friday, October 7, 2022 at 2:16:03 PM UTC-7 Matthias Koeppe wrote:

John, your proposed Oct 1 deadline (from your message on Sep 16)

Sorry, I should have written: "your proposed Oct 1 start date of the vote."

 

[seb....@gmail.com]

If a few people felt the need to delay, that should have an effect.

Surely! But indeed there was an (maybe to small) effect in the migration vote. On September 14, I suggested a compromise between David’s first proposal and Thierry’s intervention for delay. This has been taken into account in the final proposal.

​