On Fri, Sep 16, 2022 at 9:19 AM David Roe <roed.m...@gmail.com> wrote: > > I've started working on a list of pros and cons 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.
But on the other hand, if, say, the release manager didn't want to move (like Jeroen did in the past) then we wouldn't be able to move (without finding another release manager). Saying this, looks like the release manager should have (almost) veto powers here. > * There hasn't been much discussion of Github vs Gitlab on this thread, but > theoretically there are three choices in play. I think that given my negative experience with GitLab, I won't want to even consider participating in a potential trac -> GitLab move, this is technically trickier, due to different low-level APIs to be used in migration tools. And GitLab is not in a very good shape in general, compared to GitLab; we don't want to spent a lot of effort to move to a platform that might fold in some way soon. Besides, given our extensive use of GitHub CI (Actions), and uselessness of the corresponding GitLab options, GitHub is a clear preference. Integrating GitHub Actions with a GitLab repo, or finding a way to use GitLab for CI is an extra burden. Everyone who prefers GitLab should be asked a question whether he'd be willing to work on these rather tricky and thankless tasks. I'd rather focus the vote primarily on the move away from trac, not specifying whether it's GitHub or GitLab. > 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 variant, but with three options and Github and Gitlab more > similar to each other than to trac, I propose Ranked pairs for a voting > system. I suspect there may be voting theory experts lurking, so I'm happy > to hear other opinions. I'll have a word with my in-house voting theory expert :-) > * 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. I don't see why all of a sudden we talk about 2/3rds, not a simple majority. Have we ever had a vote which was not a simple majority vote here? In the absense of a written "constitution", i.e. in a precedence-based system, deviating from the existing precedence requires a separate action (maybe in form of a civil war :-)). If we must vote on this topc (as you know, I'm against this) let's do simple majority. Dima > > 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 is still in > flux). > David > > On Fri, Sep 16, 2022 at 3:41 AM Matthias Koeppe <matthiaskoe...@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+unsubscr...@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. > > -- > You received this message because you are subscribed to a topic in the Google > Groups "sage-devel" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/sage-devel/ayOL8_bzOfk/unsubscribe. > To unsubscribe from this group and all its topics, 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/CAChs6_%3D6zVgMyPV7i4O%2BGz4iBOnaB3jQHQQeRmmKgOJ1-9sknw%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/CAAWYfq0ut1D8Y9Mwqf_nV4TJMsrFWpyjU0nqWmb-VXTo4hFizg%40mail.gmail.com.
