I hope we don't introduce something akin to the US Senate filibuster :-) On Thu, Oct 6, 2022 at 5:26 PM William Stein <[email protected]> wrote: > > On Thu, Oct 6, 2022 at 8:45 AM John H Palmieri <[email protected]> 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 [email protected] wrote: > >> > >> On Wed, Oct 5, 2022 at 8:09 PM John H Palmieri <[email protected]> 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 [email protected]. > >> > 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 [email protected]. > > 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 [email protected]. > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq3A9fD6GZih6MDcg_sDMVQ9SmFoWvZTTyjBeKgOgQCDTw%40mail.gmail.com.
