llvm dev - Jan 2022 - LLVM Discourse migration: goals justify means?

> On Jan 27, 2022, at 8:42 AM, Joshua Cranmer via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> On 1/26/2022 5:36 PM, Roman Lebedev via llvm-dev 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")
> 
> I agree with virtually everything else that has been said in this thread,
so I'll limit this to saying things that I haven't seen said yet.
> 
> If you look at the history of the big infrastructure changes LLVM has made
in the recent past, there's a worrying trend. The first big change I'm
thinking of was the move from SVN to git via github. The discussion period for
this change was quite long (several years), but the actual migration I remember
as being relatively smooth. More recently, we had the move from Bugzilla to
Github issues. The discussion period was similarly long, but the migration was
far from smooth: the final notification (including things contributors needed to
do) seemed to come out of nowhere, with short timetables, and over a holiday
week, and the actual conversion process ran into several technical issues (to be
fair, many of them were not easily foreseeable).
> 
> Now we have the migration to Discourse, where the previous discussion was
arguably more contentious than the bug move and seemed to be left in a "no
consensus" state. And again we have a very-little-notice announcement of
the move, including a late Friday night or early Saturday morning announcement
on a holiday weekend. And again, there are technical issues--the "mailing
list mode" feature. However, this one really ought to have been foreseen:
the amount of emails that llvm mailing lists send out a day should be *really*
easy to estimate, so how is it a surprise that we're using too many emails?
It is really easy to throw out accusations like it should have been really easy
to estimate and that we should have known. There were steps in the process that
did change along the way even when we had laid out a plan. Things happen that
are outside our control.

I’m sorry that a transition did not go absolutely perfectly. Obviously, we want
things to go smooth. Many of the things we have done (ie bugzilla migration of
that size) have not been done before and we may be the first people to do them.
There will always be some things that pop up.
> 
> The worrying thing is the extrapolation to the "next"
infrastructure change, the move to PRs... which is the most contentious of the
lot, with several contributors outright saying that it may cause them to stop
contributing altogether. The infrastructure process clearly *isn't* working
well right now, and I think we need to step back and fix that process before
risking contributor loss.
> 
> I originally wasn't going to bring this up, but I think the decision to
disable "mailing list mode" absolutely needs to part of the "what
went wrong" postmortem. There may be a good reason why the problem of LLVM
discourse sending too many emails wasn't foreseeable beforehand, but I'm
not seeing it right now--it's important to understand where the blind spots
of the infrastructure group exist right now. But the communication of the
disabling of this feature really leaves something to be desired: it was
announced on Discourse, after it had been disabled, so that everybody who was
solely relying on it for email *never saw they had been cut off*. I myself only
found out about this because it was mentioned in the IRC channel.
This was actually posted BEFORE I disabled it. However, because of the email
situation were were in with emails being throttled, it apparently did not get
sent. That was not intentional. Again, some compassion and understanding would
be nice.
> 
> In a broader sense, I want to part with this observation. In my experience,
large projects develop a kind of "in-group", a set of people who need
to be interacted with to get things done in the project. Of the projects
I've worked with, LLVM has had the most opaque "in-group", in the
sense that it's difficult for a beginner (or even more experienced
contributors) to figure out who you need to get to review a patch, or when
you've got enough agreement on an RFC to move forward with implementation.
This is a bigger issue with LLVM in general, but the risk with respect to
infrastructure in particular is that I am extremely worried that the LLVM
infrastructure group is pushing away much or all of the "in-group",
and that has incumbent risks for the future health of the project as a whole.
The Infrastructure Working group is open to anyone. 

-Tanya
> 
> -- 
> Joshua Cranmer
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On 1/27/2022 12:31 PM, Tanya Lattner wrote:
> It is really easy to throw out accusations like it should have been really
easy to estimate and that we should have known. There were steps in the process
that did change along the way even when we had laid out a plan. Things happen
that are outside our control.
>
> I’m sorry that a transition did not go absolutely perfectly. Obviously, we
want things to go smooth. Many of the things we have done (ie bugzilla migration
of that size) have not been done before and we may be the first people to do
them. There will always be some things that pop up.
I am well-acquainted with things that ought to be easy turning out to be 
extraordinarily difficult (this was my baptism in open source, after 
all); when I'm commenting that it seems like it *ought* to be simple, 
I'm trying to understand why it *isn't*. I know that you, and the others
working on this, are intelligent people who are unlikely to miss obvious 
things, so if something like that seems to be the case... I want to 
understand *why*.

-- 
Joshua Cranmer

On 1/27/22 09:31, Tanya Lattner via llvm-dev wrote:
>> In a broader sense, I want to part with this observation. In my
experience, large projects develop a kind of "in-group", a set of
people who need to be interacted with to get things done in the project. Of the
projects I've worked with, LLVM has had the most opaque
"in-group", in the sense that it's difficult for a beginner (or
even more experienced contributors) to figure out who you need to get to review
a patch, or when you've got enough agreement on an RFC to move forward with
implementation. This is a bigger issue with LLVM in general, but the risk with
respect to infrastructure in particular is that I am extremely worried that the
LLVM infrastructure group is pushing away much or all of the
"in-group", and that has incumbent risks for the future health of the
project as a whole.
> The Infrastructure Working group is open to anyone.
Speaking as someone who joined the IWG, provided strongly negative 
feedback on the proposed discourse transitions, and then resigned 
because I didn't want my name associated with an effort likely to be so 
disastrous, I strongly question this assertion.

"We value your feedback" is pretty meaningless when that feedback is 
ignored.

(Apologies if this comes across as too snarky.  I tried to reword this a 
couple of times, but couldn't find a way to do so without loosing the 
important point.)

Philip