Aaron Ballman via llvm-dev
2022-Jan-27 14:03 UTC
[llvm-dev] LLVM Discourse migration: goals justify means?
I also found this decision to be really surprising and disappointing. I was surprised to hear a decision had been made at all, because the last public discussion about the switch was over six months ago, there was no clear consensus that I could see, and there were several unanswered questions and concerns raised on that thread. To me, this says that consensus was either not formed or was formed via a process that is completely opaque to me as a code owner and active contributor. It also gives me the impression that asking questions or providing feedback during an infrastructure RFC is largely a waste of time. Frankly, I find our RFC process to be untenable when it comes to decisions that impact the whole community; we have no idea what consensus looks like so the end result is continually "do it and the community will adapt or the people who disagree will leave." I was also surprised to get an email after 2am on a Friday night (East Coast, US) telling me that the switch was happening and I should sign up to Discourse within two days or risk disruption. Coupled with the lack of communication that any decision was even being considered, I thought this could have been handled better with a more reasonable timeline. Unfortunately, I don't see a good path forward from here. We now have Discourse, people are using it and folks who are happy about it will very reasonably wish to continue to do so, and anyway, we have no good (trivial) way to migrate back to a mailing list without losing the information now contained only on Discourse. We now also have people who are not able to use Discourse for whatever variety of reasons. So we've fractured our communication channels and caused some hard feelings, again. However, unlike with Discord, the decision to move to Discourse impacts everyone in the community, not just the people opting to use an alternate means of ad hoc discussion, because our current RFC process now means you have to be on Discourse. I think pausing the timeline to give the infrastructure team the time and space to work out the usability issues with the service is a reasonable measure, but if the answer winds up being "sorry, we can't do that" (as happened a few times with the switch from Bugzilla to GitHub Issues), I don't know what we do aside from accepting it as the new reality and potentially losing input from more members of the community as a result. So I very much share Roman's concern about the discussions around code review tools, as that's another "impacts everyone in the community" decision where judging consensus will be hard. Because of that, and orthogonal to the discussions about Discourse, I would very much appreciate it if we could have some idea of how consensus is being judged for decisions that impact the entire community. I do not have faith that the current process is working or tenable, and it seems critical (to me, at least) to solve that before making further infrastructure decisions. ~Aaron On Wed, Jan 26, 2022 at 5:37 PM Roman Lebedev via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > Hi all. > > As most of us here learned on Jan 7, apparently, we, > the LLVM community, have overwhelmingly supported > the decision to move to Discourse. > > It already raises a question as to how said decision was made, > and what exactly said "majority of the community" is. > While it is true that the LLVM RFC process is unclear at best, > in this particular case the problem becomes exceptionally egregious. > > While it may be a selection bias, as a data point, > everybody, that i regularly talk to, in #llvm IRC > were just as surprised to learn of said development as I was. > > There was no indication on e.g. llvm-dev@, > and in fact the last mention of the migration was: > https://lists.llvm.org/pipermail/cfe-dev/2021-June/068449.html > (over half a year ago!), but even if you just look at said thread, > there were certain comments that weren't addressed, e.g. > https://lists.llvm.org/pipermail/cfe-dev/2021-June/068406.html > > Hopefully, the "vote" wasn't held at the discourse itself, > otherwise it very much mirrors certain recent & future world events, > and does not paint the LLVM in a good light. > > I'm fearful that the same story is bound to happen yet again > with GitHub Pull Request migration, that all the multitude of complaints > that were received each time they were requested (and that happened > a number of times, hopefully not to exhaust those providing said feedback!) > will be just swept away and ignored, and the switch be pushed through > regardless, in the name of a noble "lowering the barrier of entry" goal. > (There's similar question about discord "RFC") > > So the first point I would like to raise is: > such painful, community-wide decisions **can not** be made in secret. > One way or another, it's going to affect every single LLVM developer, > be it one working on the upstream LLVM, or some downstream fork, > or those just wishing to keep up with the project. > **There should be transparency and accountability.** > > The second question I would like to raise is: > the blog post claims transparent, first-class email support, > but the mailing list mode can not actually be toggled on. > There is just no such checkbox, unlike some other discourse forum. > For me personally, that is a deal-breaker, and unless I'm able to > keep up to date with the discussions in the lists format, > I'm simply going to stop following discussions, period. > > While, I, personally, have not had much hands-on experience with > LLVM's discourse, mainly it's email side, I hear the situation > is not what the blogpost claims it to be, and there are other things > that aren't "just work", and that was known months ago, e.g.: > https://llvm.discourse.group/t/discourse-as-mailing-list-replacement-some-questions/3713/4 > > Given that the hard switch point of Feb 1'st has already been set, > and is less than a week away, i'd like to hear some clarification > as to what is going on, and strongly recommend doing either of the following: > * STOP migration(s) due to "false start", the end status already being decided > before the process even begun, and using the process just as a means > to legalize the decision made beforehand. > * postponing the switch by a month (until March 1'st), or however long needed, > effectively immediately, in order to make the migration actually possible > by working out the issues that have come up during the migration. > > While what is written above is my personal view on things, > I do **not** believe the said view is unique to me. > > What are the foundation's thoughts on this? > > Roman > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Tom Stellard via llvm-dev
2022-Jan-27 15:12 UTC
[llvm-dev] LLVM Discourse migration: goals justify means?
On 1/27/22 06:03, Aaron Ballman via llvm-dev wrote:> I also found this decision to be really surprising and disappointing. > > I was surprised to hear a decision had been made at all, because the > last public discussion about the switch was over six months ago, there > was no clear consensus that I could see, and there were several > unanswered questions and concerns raised on that thread. To me, this > says that consensus was either not formed or was formed via a process > that is completely opaque to me as a code owner and active > contributor. It also gives me the impression that asking questions or > providing feedback during an infrastructure RFC is largely a waste of > time. Frankly, I find our RFC process to be untenable when it comes to > decisions that impact the whole community; we have no idea what > consensus looks like so the end result is continually "do it and the > community will adapt or the people who disagree will leave." > > I was also surprised to get an email after 2am on a Friday night (East > Coast, US) telling me that the switch was happening and I should sign > up to Discourse within two days or risk disruption. Coupled with the > lack of communication that any decision was even being considered, I > thought this could have been handled better with a more reasonable > timeline. > > Unfortunately, I don't see a good path forward from here. We now have > Discourse, people are using it and folks who are happy about it will > very reasonably wish to continue to do so, and anyway, we have no good > (trivial) way to migrate back to a mailing list without losing the > information now contained only on Discourse. We now also have people > who are not able to use Discourse for whatever variety of reasons. So > we've fractured our communication channels and caused some hard > feelings, again. However, unlike with Discord, the decision to move to > Discourse impacts everyone in the community, not just the people > opting to use an alternate means of ad hoc discussion, because our > current RFC process now means you have to be on Discourse. I think > pausing the timeline to give the infrastructure team the time and > space to work out the usability issues with the service is a > reasonable measure, but if the answer winds up being "sorry, we can't > do that" (as happened a few times with the switch from Bugzilla to > GitHub Issues), I don't know what we do aside from accepting it as the > new reality and potentially losing input from more members of the > community as a result. >Hi, Do you have more information about who is unable to use Discourse and why? -Tom> So I very much share Roman's concern about the discussions around code > review tools, as that's another "impacts everyone in the community" > decision where judging consensus will be hard. Because of that, and > orthogonal to the discussions about Discourse, I would very much > appreciate it if we could have some idea of how consensus is being > judged for decisions that impact the entire community. I do not have > faith that the current process is working or tenable, and it seems > critical (to me, at least) to solve that before making further > infrastructure decisions. > > ~Aaron > > On Wed, Jan 26, 2022 at 5:37 PM Roman Lebedev via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> Hi all. >> >> As most of us here learned on Jan 7, apparently, we, >> the LLVM community, have overwhelmingly supported >> the decision to move to Discourse. >> >> It already raises a question as to how said decision was made, >> and what exactly said "majority of the community" is. >> While it is true that the LLVM RFC process is unclear at best, >> in this particular case the problem becomes exceptionally egregious. >> >> While it may be a selection bias, as a data point, >> everybody, that i regularly talk to, in #llvm IRC >> were just as surprised to learn of said development as I was. >> >> There was no indication on e.g. llvm-dev@, >> and in fact the last mention of the migration was: >> https://lists.llvm.org/pipermail/cfe-dev/2021-June/068449.html >> (over half a year ago!), but even if you just look at said thread, >> there were certain comments that weren't addressed, e.g. >> https://lists.llvm.org/pipermail/cfe-dev/2021-June/068406.html >> >> Hopefully, the "vote" wasn't held at the discourse itself, >> otherwise it very much mirrors certain recent & future world events, >> and does not paint the LLVM in a good light. >> >> I'm fearful that the same story is bound to happen yet again >> with GitHub Pull Request migration, that all the multitude of complaints >> that were received each time they were requested (and that happened >> a number of times, hopefully not to exhaust those providing said feedback!) >> will be just swept away and ignored, and the switch be pushed through >> regardless, in the name of a noble "lowering the barrier of entry" goal. >> (There's similar question about discord "RFC") >> >> So the first point I would like to raise is: >> such painful, community-wide decisions **can not** be made in secret. >> One way or another, it's going to affect every single LLVM developer, >> be it one working on the upstream LLVM, or some downstream fork, >> or those just wishing to keep up with the project. >> **There should be transparency and accountability.** >> >> The second question I would like to raise is: >> the blog post claims transparent, first-class email support, >> but the mailing list mode can not actually be toggled on. >> There is just no such checkbox, unlike some other discourse forum. >> For me personally, that is a deal-breaker, and unless I'm able to >> keep up to date with the discussions in the lists format, >> I'm simply going to stop following discussions, period. >> >> While, I, personally, have not had much hands-on experience with >> LLVM's discourse, mainly it's email side, I hear the situation >> is not what the blogpost claims it to be, and there are other things >> that aren't "just work", and that was known months ago, e.g.: >> https://llvm.discourse.group/t/discourse-as-mailing-list-replacement-some-questions/3713/4 >> >> Given that the hard switch point of Feb 1'st has already been set, >> and is less than a week away, i'd like to hear some clarification >> as to what is going on, and strongly recommend doing either of the following: >> * STOP migration(s) due to "false start", the end status already being decided >> before the process even begun, and using the process just as a means >> to legalize the decision made beforehand. >> * postponing the switch by a month (until March 1'st), or however long needed, >> effectively immediately, in order to make the migration actually possible >> by working out the issues that have come up during the migration. >> >> While what is written above is my personal view on things, >> I do **not** believe the said view is unique to me. >> >> What are the foundation's thoughts on this? >> >> Roman >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev