<div dir="ltr"><div dir="ltr">On Thu, Oct 7, 2021 at 3:44 PM Renato Golin <<a href="mailto:rengolin@gmail.com">rengolin@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Thu, 7 Oct 2021 at 23:16, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">I don't think diversity necessarily relates to this aspect of managerial structure. Unless we're talking about the less benevolent dictatorships where the authority figures both provide structure, but also set some fairly negative tones for how people should relate. Those things aren't necessarily connected though, and I don't see signs that's the kind of leadership we have or are moving towards in the LLVM community. <br></div></div></blockquote><div><br></div><div>Sorry, that's not at all what I meant.</div><div><br></div><div>LLVM attract all kinds of people, not just from different backgrounds and minorities, but also different cultures. And by culture I mean a lot of things.</div><div><br></div><div>We have different countries and continents; academia, enterprise and government; students, professionals, directors; enthusiasts or people just trying to make some money; open and closed source source projects; embedded into or built as a library or being used by a dependency. I myself have belonged to many of those groups over the years.</div><div><br></div><div>In my opinion, that variety in how we all use and rely on LLVM is key to its success, but it's also what makes it hard to drive larger changes that affect the least amount of people.</div><div><br></div><div>Even foundations and working groups can't be representative of all people and most of the time we don't even know who "the people" are until we try to change something and it breaks for them.</div><div><br></div><div>This is why long consensus "works" for us, because eventually by then, most people would have seen it and voiced their opinions. But it's slow and painful.</div><div><br></div><div>I personally prefer that pain, then the pain of seeing each new decision alienating a small, but substantial, part of the community, and making the project less and less palatable to new contributors from different cultures.</div></div></div></blockquote><div><br></div><div>Not making changes (or making them especially slowly) can also exclude people, which is one of the things we're grappling with in this decision too (every patch that comes in through a pull request and is automatically rejected - where that contributor doesn't then go and do all the extra work of figuring out phab, creating an account, etc, is lost new contributions/contributors, for instance)<br><br>I don't think the longer process we've used in the past necessarily created higher quality decisions - I think moving to github, preserving commit/author history, and maintaining a linear version history might've been a decision that could've been made (& would likely have been made, moreso than other options that were considered) relatively quickly, for instance.<br><br>All this said - I think the place where the IWG/board can be most helpful is to lower the costs of dealing with the infrastructure problems - in the github migration, figuring out tooling to preserve history/manage the migration and enforce the linear version history, etc - that took time to consult with github, build scripts and test them, etc. Doing that pre-emptively/more aggressively and being able to demonstrate a path forward to the community would probably be pretty helpful.<br><br>Similarly, taking the feedback from a review like this around github pull requests for review, and using whatever weight/consulting/paid consultants/contractors/etc might be available to help implement any feasible feature improvements to smooth the transition might be quite helpful. (tricky to frame that as "exploratory"/lowering barriers without it being "we've already decided the direction and the community will just have to accept it" is tricky, and how much of that sort of work is worth doing without it being clear that the work will be used/will pay off in the end - that's complicated) But hopefully a general "what're the concerns, how broad reaching are they/how many people have them" and then some time to figure out how feasible addressing each of them is, what sort of timeframe, etc, seems like a place to start.<br><br>- Dave<br><br> <br></div></div></div>