On Fri, 16 Sep 2022, 17:20 kcrisman, <kcris...@gmail.com> wrote: > > 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 :-) >> > > Who will surely point out the inseparability of the various yes/no options > here. Voting system choice is more a sociological matter, in my view, > which I think is well supported by the arguments of the authors of > "Properties of Multiwinner Voting Rules, Soc. Ch. Welf. 48:599-632" about > different goals for "committee" choices in different contexts. > > > * 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? >> > > This was my suggestion (suggestion only). Namely, with a 2/3 vote, half > the people who voted in favor would have to change their mind to then vote > for a different switch. (Of course, the place that most benefits is if all > votes are 2/3, which wouldn't be the case here.) I do feel like we have > had one or two "supermajority" consensus-seeking situations, but not > formally so, and no, I can't find them now. > > The primary reason I suggested it, though, was to take the emphasis away > from the controversial aspect, and have the community feel like whatever > decision is made is one there is strong support for, which then the rest > might grudgingly agree to for the good of the project (in a worst-case > scenario; my hope is no grudges!). Moving to GH to potentially attract new > developers isn't super helpful if a significant number of long-time, > *experienced* developers might leave; > likewise, staying on Trac isn't helpful if some developers (and > particularly maintainers) say they just can't do it any more because it's > so broken. > So this is a real danger. Since a choice of system could lead to a very > divisive result, or alternately be too confusing for many people to fully > participate, I made a possible suggestion. > > However the vote is structured (yes, we voting theorists also do stupid > things like voting on voting systems ...), in my view the primary > importance is finding a solution that dozens of our most valuable > contributors (front-end and back-end) can at least live with, and then have > a purely pro forma vote on that. Otherwise we could have literally dozens > of options, many of which it's unclear from this thread whether they are > even realistic. Is the following link helpful in that regard? > > > https://docs.gitlab.com/ee/user/project/import/github.html#mirror-a-repository-and-share-pipeline-status > > It seems like it really would be possible to move to GH, and then have any > interested volunteers who care deeply about GH versus GL set up a mirror. > (Presumably Premium GL is still a lot cheaper than Google Cloud hosting of > Trac? That might be wrong.) Or even to set up a self-hosted GL mirror on > an academic account. >
bility to set up any infrastructure on academic premises is more of wishful thinking. It's next to impossible due to too much red tape - and lack of reliability. I feel like something along these lines would a) not waste the effort > already made at putting together a proposal to move to GH b) alleviate some > concerns over GH longevity/policies c) put the work on the GH move on > people who want to leave Trac and the work on a GL move on those who want > to stay, so such load seems more equitable. > > Perhaps one could then have a true (even majority up/down) vote on leaving > Trac, with the understanding that there is no objection or even > encouragement to finding GH substitutes to stand in if/when necessary, > maybe even for syncing. > Indeed, this would simplify the thing a lot. Sort of like how many of the 13 North American British colonies only voted > for the Constitution with the guarantee (implicit) that the Bill of Rights > would be immediately forthcoming ... nah, that's a bit too dramatic! > we live here without a written construction, akin to UK. It only worked in UK (and for Sage) while it was understood and maintained that unwritten rules of gentleman-like conduct are upheld, in particular being obviously wrong should have consequences for these being wrong, these in the wrong should admit it and face the consequences. Unfortunately for Sage we see it's possible now to go and start breaking things, so that other people had to jump to the rescue to mitigate the breakage, and then pretend that everything went as planned, without any apologies, any admittance of guilt. That's in a way similar to what's going on in UK in the past 10 years or so, it became increasingly acceptable for politicians and government in power to go spectacularly wrong, and remain in power, rather than resign. But we digressed :-) > -- > 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/f92bd0d2-f732-4abd-b874-ffbbe6df2189n%40googlegroups.com > <https://groups.google.com/d/msgid/sage-devel/f92bd0d2-f732-4abd-b874-ffbbe6df2189n%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/CAAWYfq2LSrUzQMdJUHk5icXM6_%3D%3DDsZNGpVWNJ5a53yiBsuJYg%40mail.gmail.com.
