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
On Wednesday, October 5, 2022 at 9:18:04 PM UTC-7 wst...@gmail.com wrote:
> 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
>
> >
> > --
> > John
> >
> >
> >
> > On Wednesday, October 5, 2022 at 3:11:12 AM UTC-7 Thierry
> (sage-googlesucks@xxx) wrote:
> >>
> >> 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
> >>
> > --
> > 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)
>
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/bf5f5f37-72b1-4c2f-9289-a7ff61d0aae2n%40googlegroups.com.
