discourse_migration: Complete the mailing list to Discouse mappings

[tstellar]

What about something like this:

• clang
  • dev
  • users
  • clangd
• libcxx
  • users
  • dev
  • libunwind
  • parallel-libs
• lldb
  • users
  • dev
• Runtimes
  • sanitizers
  • libclc
  • openmp
• flang
  • users
  • dev
• llvm
  • users
  • dev

[tstellar]

I forgot about lld, that probably deserves a top-level category too. I thin it might be good to keep the llvm-project top-level category and put the releases sub-category there and maybe documentation too? I don't really know what to do about the beginners category, to me that is more or less the same as the users category.

[joker-eph]

Users in clang exists for people who are really end-users of the tool and not developers. Beginner is more about people who are trying to get started with developing inside clang instead. The same logic may apply to other project I guess...

@tlattner : originally MLIR was also under LLVM project and we asked to move out so that we can have subcategories (Discourse limits to one level of nesting). But the current setup otherwise was very intentional, I'll ping Meike so that she can elaborate a bit on this maybe: I think she had thoughts about the tradeoff.

[Somae]

@joker-eph thank you for pining me.

We can of course make all of these things top level categories, but it will make the main page very crowded and hard to orient. It makes a lot of sense to me to create a few more top level categories, but I don't see the strict need for all of them.

Cases where I think we will have a benefit: If something, like MLIR did back then, has multiple subcategories (MLIR main category plus 3 subcategories). What is the purpose of the top level categories you are proposing? Usually you can open topics in it as well, and MLIR uses it for the main discussions. Should the main category be the equivalent of the users category? Or dev? We could also establish the already existing LLVM top level category as the equivalent of either of those. If we have a clear vision here and still think everything should be a main category, we can make those changes of course, but I'd like us to have a plan what kind of discussions we want to facilitate where. Wild suggestion as example what I mean: We could even do a split between a "users" main category and a "dev" main category, which is the split for most and also a distinct set of users, probably, and then for the few bigger areas elevate them to top level categories. We can make any grouping we think where a top level discussion category might also have a place, in Discourse logic.

I'm actually quite fond of the Beginner category. It's better for beginners to have something simple to turn to, because they probably don't even know yet where they should be asking their questions. It's the same way the #beginners channel on Discord is nice and simple and helps people. Having this category and the corresponding channel on Discord was one of the main drivers to start these in the first place, after all.

For announcements, wouldn't it make more sense to have them as the first subcategory of the main category they are announcements for, just like we did with MLIR? So that people who look at it immediately see is as the first thing in the category.

[tstellar]

@Somae I had the same concern you did that a lot of top-level categories would make the main page too cluttered, but after looking at the current landing page, I don't think it will be a problem after all, but this probably depends a lot on personal preference.

You make a good point about posting in the main category. For me, the fact that you can post in the main category when sub-categories exist is confusing. Is there some way to disallow posting in the main category?

[tlattner]

I believe that Announcements should be a top level category and at the top of the list. Not buried within something else. This would include things such as releases, blog posts (so people can have discussion), dev mtg announcements. It avoids the need to cross post to different "lists" like we do now and easy for people to find. A good example of this is on the Swift Forums.

I agree that having every sub-project as its own top level category might be a lot. I was asking more what the criteria would be that a project has its own top level category. We should define that to make it more clear. LLVM is a large project and while that might make the forums bigger by having many top level categories, we should do that if projects require the subcategories and it makes sense. I think lumping everything into LLVM Project is a lot. It also makes it seem like MLIR and anything else outside of it is not a part of the LLVM Project.

Right now, the cfe-users list has low subscriptions and low posts. In my opinion, the nature of the mailing list setup caused this problem (separation due to having to sign up for multiple lists). Discourse will hopefully help solve it and help users get the answers they need and developers be able to see the posts more easily. I think we should think carefully about how to get the most engagement and help for users of Clang versus the current setup. This applies to other projects as well.

I'm not anti-Beginners category but I'm just wondering how successful it will be when we move everything over. LLVM Project is really large. Will the right people be reading and responding to beginners? Will people be able to easily filter out beginner questions to their area of expertise? Would it make more sense to have a Beginners category in sub-projects?

[joker-eph]

I'm not anti-Beginners category but I'm just wondering how successful it will be when we move everything over. LLVM Project is really large. Will the right people be reading and responding to beginners? Will people be able to easily filter out beginner questions to their area of expertise? Would it make more sense to have a Beginners category in sub-projects?

We kind of already have this problem on Discord, for example beginner in MLIR may be asking questions in the beginner channel, but because no one will answer they will be redirected to the MLIR channel (where we welcome beginners of course! ;) ).

The same may exist for lld or other subproject: the people willing to help beginners with lld may not want to triage the beginner channel when most of the requests are for llvm or clang?

[tlattner]

I'm not anti-Beginners category but I'm just wondering how successful it will be when we move everything over. LLVM Project is really large. Will the right people be reading and responding to beginners? Will people be able to easily filter out beginner questions to their area of expertise? Would it make more sense to have a Beginners category in sub-projects?

We kind of already have this problem on Discord, for example beginner in MLIR may be asking questions in the beginner channel, but because no one will answer they will be redirected to the MLIR channel (where we welcome beginners of course! ;) ).

The same may exist for lld or other subproject: the people willing to help beginners with lld may not want to triage the beginner channel when most of the requests are for llvm or clang?

This is good information to know and something we should really consider what is the best Beginner experience and what will result in their questions being answered.

[tstellar]

I think we should resist creating separate developer and user sub-categories unless it's for a very high-traffic category. For me, I think clang is probably the only category that needs the split. You could probably make the case to have a separate user sub-category for llvm, but what is an llvm user? A library user? A user of the bintuils replicas? I don't really know.

[Somae]

I agree that there should be more top level categories, and also +1 for renaming the "LLVM Project" top category as it can be quite misleading. As long as we find a good balance of number of top level categories, I think it will be a great improvement to what we have right now. When elevating some subprojects to a top level category, maybe it is worth thinking about if more subcategories would make sense? Some mailing lists are quite high traffic now, and as soon as people don't have to subscribe to different mailing lists anymore to follow various topics, it might be worth splitting some "dev" up, for example. What are your thoughts? On Discord for example we have a more fine grain channel distribution right now.

It seems like we could take away posting rights from users for top level categories. We can't really make them just structural elements - they will continue to be forums.

The Beginner topic is a really hard one. It would be great to not have a place where some people have to triage, but that might result in people turning away who don't know where to ask their question, such increasing the barrier to asking the question in the first place. It's also not feasible for everyone to triage Beginners all the time. As long as redirecting or pinging members from the various communities works, it doesn't seem like the worst option either. Helping beginner triage could be a way to support the LLVM community, and we could make it so that topics are moved into the right category, for example, or something similar. Just trying to brainstorm here.

[tstellar]

I want to focus on the 'project' categories, since we need to get the mailman -> Discourse mappings done in order to start the migration. I think for new topics like Beginner, we have more time to discuss and try to get right.

Here is a revised proposal for the project categories with less top-level and overall categories than my previous proposal. What do you think?

• clang (Developer discussion on the top-level category)
  • users
  • clangd
• llvm
  • lld
• runtimes
  • libcxx (includes parallel-libs, libunwind).
  • sanitizers
  • openmp
  • libclc
• flang
• lldb

Once we get this set, the last thing we need to complete the mappings is the announce /release-testers categories.

[Somae]

I think that looks like a really reasonable proposal, Tom! Thank you for putting so much consideration into this. Flang and LLDB can reasonably stand on their own, and maybe they'd like to have some sort of sub-categories at some point.

I'm happy to implement those changes on the Discourse end. Should we use a logo for some of these top level categories? If so, which specific ones?

[tlattner]

@lattner Adding Chris to this thread.

Sorry to drag this out. I think we are heading in the right direction. I can understand wanting to just focus on projects and the lists, but I see this as an opportunity to make some changes. I see 2 main problems from our current mailing list setups. 1) Lists like LLVM-dev are a firehose and need to be split 2) Making sure the right people are there to answer the questions (ie. users, beginners, etc). I think we should design the discourse categories to solve as much of the problems as we can and not to design them around the mistakes we have made in the past. This may mean that a list doesn't get mapped to a new discourse category. For example, I would like to propose that we put LLVM dev into an LLVM Dev List Archive category and then any recent and important posts from the import can be moved to the right category.

I would also suggest that we not limit our category names to one word. :)

I would want to see something like

Announce (to solve the cross posting issue and have a controlled and low volume category) Clang Compiler & Tools

• Using Clang
• Building Clang
• clangd LLVM Based Subprojects
  • lld
  • flang (I would put flang here unless its big enough to warrant a whole category)
  • lldb (may need top level but haven't looked at the traffic there)
  • Static Analyzer (should we have one for this?) LLVM Code Generation
  • (we should have subcategories for all the major backends)
  • Other (named something better but for smaller backends) LLVM IR & Optimizations
  • Sub categories such as a loop optimizations, etc LLVM Dev List Archives Community Infrastructure
  • Policies (we should add this as a subcategory to discuss project wide policies) Runtimes
  • Your list is good

I'm also coming around to keeping Beginners as I don't love having one in each major category. I think we should consider moving questions more aggressively to the right category when it makes sense to encourage the right people to respond.

[tlattner]

Let's try this again as the formatting got removed. Also, after thinking more,I think relying on tags is probably not a good approach as no one is forced to use them versus picking a category, they are.

• Announce (to solve the cross posting issue and have a controlled and low volume category)
• Clang Compiler & Tools
  • Using Clang
  • Building Clang
  • clangd
• LLVM Based Subprojects
  • lld
  • flang (I would put flang here unless its big enough to warrant a whole category)
  • lldb (may need top level but haven't looked at the traffic there)
  • Static Analyzer (should we have one for this?)
• LLVM Code Generation
  • X86, ARM, (we should have subcategories for all the major backends)
  • Other (named something better but for smaller backends)
• LLVM IR & Optimizations
  • Sub categories such as a loop optimizations, etc
• LLVM Dev List Archives
• Community
  • Keep what we have, add as needed
• Infrastructure
  • Add a Policies category (we should add this as a subcategory to discuss project wide policies)
• Runtimes
  • Your list is good

[joker-eph]

I'm also coming around to keeping Beginners as I don't love having one in each major category. I think we should consider moving questions more aggressively to the right category when it makes sense to encourage the right people to respond.

One drawback of posting to a beginner category and then moving threads to the relevant project may be that the beginner category could look "empty" and "seemingly inactive" to a newcomer, who may then hesitate to post a question there (sorry I don't have a clear idea on all the tradeoff to make another suggestion though).

Otherwise I like your current proposal :)

[tstellar]

@tlattner I like this proposal too. For the "LLVM Dev List Archives" category, does this mean we will archive the existing mailing lists into sub-categories here instead of trying to archive them into the new categories?

[tlattner]

I just mean for llvm-dev, there isn’t a good place to put LLVM-dev archives if we create more top level categories for LLVM. I am suggesting that we do make these top level categories as LLVM core is so big.

As for the other lists, most can be dumped into the corresponding category/subcategory. Does that make sense? Pretty much what you already have suggested. I think I was saying keep Flang and LLDB as subcategories but we can debate that too….

We could do some archive for all of them but I think that messier…

-Tanya

On Jul 21, 2021, at 2:10 PM, Tom Stellard @.***> wrote:

 @tlattner I like this proposal too. For the "LLVM Dev List Archives" category, does this mean we will archive the existing mailing lists into sub-categories here instead of trying to archive them into the new categories?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[tstellar]

I've updated the mappings list based on Tanya's proposal. The only one we haven't really discussed yet is the release-testers list. I put in the patch that this would map to community/releases, but I'm open to other suggestions.

[tstellar]

@tlattner Can you take a quick look at the final list of mailing lists -> Discourse categories and confirm it looks OK, so I can send it off to the Discourse team?

[lattner]

A couple other questions:

• Will this also remove/replace the existing "LLVM Project" section, or is that a second step?
• Is it possible to move this from https://llvm.discourse.group/ to the more conventional forums.llvm.org URL?

[lattner]

Ah, I just saw Tanya's comment above. I think it would be great to have a "Target Specific" category, then "X86, ARM, RISC-V, ..., Other" underneath it. We can't really auto-populate that right now, but those will likely have their own different interest groups and it makes total sense to carve that out as a top level thing in the forum, given it is orthogonal to the frontends and runtimes.

[tlattner]

I think the main thing left is Release Testing. I was sorta leaning towards having it being a top level category and then sub topics could be per-release type? Maybe this is overkill? Community just doesn't feel like the right spot for it though and its cross project. I do think we can put it under Community and move it out later, but not positive.

[tstellar]

I think I've applied all the suggestions now. I also added a file that lists all the categories and sub-categories since it was getting a little hard to follow in the comments. Please take a look and let me know what you think.

[lattner]

LGTM Tom!

[tstellar]

Summary of outstanding questions:

• What to do about Release category? (Latest suggestion is Infrastructure/Release Testing)
• Should we merge WICT and Community.o ?
• Should we merge EuroLLVM and US DevMtg?
• Should we move tools out of "Clang Frontend" and into "Subprojects"