On Fri, 16 Sep 2022, 19:54 John H Palmieri, <jhpalmier...@gmail.com> wrote:
> A few comments: > > - We have a strong history in Sage of conducting votes, and I absolutely > think we need to do that for this issue. We also have a history (with > perhaps a small number of exceptions) of having majority rule, and I think > that's what we should do here: no need for a 2/3 vote. > > An aside: I am chair of our department, and we have a governance > structure, including an executive committee. Earlier this year the > committee proposed a policy to the whole department and brought it to a > meeting for a vote. The discussion was contentious and the vote ended up > with more yes than no votes, but there were also a number of abstentions, > and the total number of yes votes was under 50% of the total present. > Shortly after, I proposed, and the executive committee accepted, that we > not put the new policy into place: our department has a strong preference > for something closer to consensus than that. Sage does not have any such > governance structure, so I don't think we can behave this way: we can't > wait until the votes are cast before deciding how to interpret the results > (not that anyone was proposing this), but I also think we can't decide that > this vote should require a supermajority. It feels very arbitrary: why this > vote but not so many others? We should hold a vote where the majority wins. > If we want to develop more of a structure, including some sort of criteria > for when we want majority votes vs. supermajority votes, we can do that, > but I don't think it makes sense to try to put it in place for this issue. > > - Regarding Gitlab: there has been very little discussion of it: the > discussion has focused on Github and trac. If we are expected to consider > Gitlab in addition, we need more information. In particular, starting a > vote early next week is too early. > I think the 1st vote should be on moving from trac to Git**b; besides it appears that, technically, move to Github is much easier than to Gitlab (while there are migration tools available for trac->github, I could not find anything for trac->gitlab). On the other hand github->gitlab move is easy (that's where gitlab gets its business from). > - Some people with strong opinions said that they are not ready to > formulate their views. > > My impression is that trac is now doing okay, > Note that trac's bus factor is down to 1/3. It took efforts of Frederick, Jan, and me to put it into the present state. Any kind of system upgrade, or VM infrastructure update, or something else, may break it, with all 3 of us possibily needed to repair it. Maybe we'd manage, maybe not. I don't think it is acceptable state of affairs, and that's why it really is strange for me that we are bothering with the vote at all. Dima and I don't see a reason to rush a vote. I would propose that people work > on David's list of pros and cons (thank you for working on that!), and we > start a vote around October 1. We may or may not want to include Gitlab > among the options; are there any actual proponents of it? > > -- > John > > > > On Friday, September 16, 2022 at 1:19:35 AM UTC-7 David Roe wrote: > >> I've started working on a list of pros and cons >> <https://github.com/sagemath/sage/wiki/Github-vs-Gitlab-vs-trac> to be >> included in the email proposing a vote. Even though I favor the switch, >> I've tried to accurately and neutrally describe the arguments in each >> direction. I welcome help and additions, but please keep them in this >> spirit (conversely, if you feel like I'm misrepresenting an argument or >> making unjustified claims, please let me know). >> >> There has also been some discussion of how the vote should be carried out. >> >> * There was a proposal to make the deadline two weeks after the call for >> the vote. That sounds fine to me. >> * I intend to include a plea for people to keep discussion on a separate >> thread rather than the voting thread. >> * There was a proposal for people who have been more involved somehow to >> have their votes count extra. I don't think this is a good idea: it's not >> clear how to draw the line or what the weighting should be, and I think >> it's more likely to cause resentment than alleviate it. >> * There hasn't been much discussion of Github vs Gitlab on this thread, >> but theoretically there are three choices in play. Given that, we face >> Arrow's theorem in picking a voting system (especially if we also want to >> allow people to abstain). I'm normally in favor of a Borda count >> <https://en.wikipedia.org/wiki/Borda_count> variant, but with three >> options and Github and Gitlab more similar to each other than to trac, I >> propose Ranked pairs <https://en.wikipedia.org/wiki/Ranked_pairs> for a >> voting system. I suspect there may be voting theory experts lurking, so >> I'm happy to hear other opinions. >> * There was a proposal to require 2/3 either in favor of a switch or not >> opposing. I'm open to this, but would be interested in hearing other >> opinions. Perhaps we allow people to abstain, and then require that at >> least 2/3 either abstain or prefer the winner to trac? With this in place, >> maybe our voting system doesn't actually matter, but it's probably safer to >> pick one. >> >> Given that I want to get feedback on the voting system and the >> pros-and-cons, I'll wait until at least Monday to send out a request for a >> vote (longer if the discussion is still going strong or if the workflow >> proposal >> <https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b> is >> still in flux). >> David >> >> On Fri, Sep 16, 2022 at 3:41 AM Matthias Koeppe <matthia...@gmail.com> >> wrote: >> >>> On Thursday, September 15, 2022 at 11:57:35 PM UTC-7 seb....@gmail.com >>> wrote: >>> >>>> About ten years before Google was on Earth someone put a poster on our >>>> corridor of the University building: *Microsoft free area*. We all >>>> were proud about that. But at that point nobody knew what should come later >>>> on. >>>> >>> >>> Of course. Many of us shared this position back in the days when >>> Microsoft was absolutely hostile to open source and in particular to the >>> GPL. >>> >>> But it's just not applicable today. Microsoft (which GitHub is a >>> subsidiary of) is the single biggest contributor to open source software. >>> >>> >>> >>> -- >>> 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/867d0ba7-22e6-466e-8350-b660c312992dn%40googlegroups.com >>> <https://groups.google.com/d/msgid/sage-devel/867d0ba7-22e6-466e-8350-b660c312992dn%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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/1bb6edc7-6d68-491c-8e43-8edd0e64d374n%40googlegroups.com > <https://groups.google.com/d/msgid/sage-devel/1bb6edc7-6d68-491c-8e43-8edd0e64d374n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAAWYfq04Sjzta9gz6pmB6QcLkb1Vvrntk99rpOHTg3ZhLzUfgg%40mail.gmail.com.
