I hope we don't introduce something akin to the US Senate filibuster :-)
On Thu, Oct 6, 2022 at 5:26 PM William Stein <wst...@gmail.com> wrote:
>
> On Thu, Oct 6, 2022 at 8:45 AM John H Palmieri <jhpalmier...@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
>
>
> >
> > 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.
>
>
>
> --
> 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/CACLE5GCAjKp9hXNMf2YJXZ4uq5pG1Q-s1xvpj_aix0WJ12hkng%40mail.gmail.com.
--
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/CAAWYfq3A9fD6GZih6MDcg_sDMVQ9SmFoWvZTTyjBeKgOgQCDTw%40mail.gmail.com.
