llvm / community.o Goto Github PK

The idea is that having a dockerfile available will remove a number of potential build issues that newcomers could struggle with.

At the moment, our sponsors donate money. This is great, and we really don't want that to stop.

Discussions at the 2024 EuroLLVM community.o workshop made it sound like we are a little short of volunteers. One idea was to allow sponsors to donate time instead of money.

Benefits:

1. Opens up a new category of sponsors. Some organisations may want to sponsor the LLVM project, but are unable or unwilling to donate money. They may, however, be willing to donate time instead. Universities or organisations based in countries with unfavourable exchange rates may be good examples,
2. We could incentivise unpopular work, for example by requiring sponsors who donate time to donate a certain fraction of their time to specific areas/projects/tickets/etc, or by saying that sponsors must donate a certain number of hours, but unpopular work will come with a multiplier so will be valued higher.

Risks:

1. We risk cannibalising our existing sponsorship deals. This could be mitigated by making the conversion rate between "cash sponsorship" and "time sponsorship" unfavourable, so it remains cheaper to donate money,
2. We risk de-valuing our sponsorship deals if too many "time sponsors" get involved. Again, this can be mitigated by making the time sponsorship expensive,
3. If the time sponsorship is too expensive, no-one will use it. Clearly, getting the pricing right will be important,
4. We increase the maintenance burden on the LLVM side. It's easy to check if money has turned up in a bank account, it's harder to check whether someone actually has done the hours they say they have,
5. How do we value time? A student may achieve in ten hours what an experienced developer would achieve in one. However, there may be value in having that student involved with the project. This is mitigated in bug trackers by using story points instead of time estimates, but accurate assignation of story points is hard and would increase the burden on the LLVM side.

Next steps:

• People who are in a position to make decisions about sponsors, pricing, and strategy need to discuss this and work out whether we are happy to proceed in principle. I don't see that we can do anything else until then. I don't know who that would be, so I'm going to tag @sqlbyme and @tlattner , who seemed keen on this idea at the conference.

Could the project aim to have one or a few mentors explicitly mentioned on every “good first issue” github issue, so that people can find out who could help them with getting started on a specific issue?

https://community-dot-o.llvm.org/wict-meetups/ is currently missing details for
https://www.meetup.com/meetup-group-ifwtlvwd/events/293949678/ and
https://www.meetup.com/meetup-group-ifwtlvwd/events/295510666/

lnihlen documented much of the process by doing this herself on the llvm forums. It would be great to have this information on a live doc that includes the work it takes, who to follow up with if it requires manual work and if it's a similar process for folks who may only want to e.g. change their email address.

The path to code owner is not documented.

We should revisit project wide policies/documentation on how code owners are nominated, how someone can set out on a path to become a code owner, and determine how to ensure that we are casting a wide net of candidates.

We need to create a list of roles within the community that provide entry points in the community and documentation on how to fulfill these roles.

Examples:

• Bug Triage
• Reviewer
• Release Testing
• Moderator

It would be great to have a bigger presence for welcoming newcomers on the main page. Tangentially this is something a professional web designer can help out with too.

At the EuroLLVM 2024 community.o workshop, many newcomers point out that a lot of areas in LLVM are underdocumented. The backend was highlighted as especially lacking.

One idea we had was that maybe the best way to improve documentation is that when the documentation isn't good enough for what you need to work on; you (as a newcomer) should write up a pull request with documentation describing how you think how it works. Even if it's wrong, that's the best way to get the people with more experience to point you in the right direction. And as a side-effect, the project's documentation improves. This should be documented clearly as a "the most powerful way to get the documentation you need to be created".

Of course, this is at odds with newcomers often feeling "social anxiety" to do anything publicly.

How could we help overcome this?

From our community.o workshop discussion:

I think the reason that most community.o issues don't get a lot of active contribution, despite good will from the llvm community in general, is that most contributors are either students or paid employees. As such, they have to "dance with the ones that brought them," and so community contribution would need to take up mostly personal time. It isn't fair to ask folks to work on community stuff with their personal time.

Some video games rely on strong community interaction, and the games industry has developed a skillset for community managers. These folks are critical for the success of online games, and are paid employees who keep busy managing their online communities. I'm not certain if there's a similar set of paid professionals with experience in open source, but I think the Foundation would have the most success on advancing community issues by having a person who is accountable for advancing the work.

The LLVM project consists of mainly a huge C++ code base.

Navigating and bit-by-bit understanding a huge C++ code base is one of the key skills people need to be able to contribute code most effectively.
Could the project document/recommend a few approaches to learn this skill?

It would be great for a bot to detect PRs, especially by newcomers, who haven't gotten a reaction.
The bot should:

1. post an apology.
2. post e.g. on Discourse a list of PRs that are waiting for a reaction for a long time.
3. Maybe, when we have volunteers to help with finding appropriate reviewers, ping them with the list.

This came out of Euro LLVM 2024 newcomer improvement roundtable

Problem is that getting toy tutorial to run is hard.

Toy tutorial could be self-contained in a separate repository; s.t. it is obvious how to do self-contained enlist, build and run it, w/o guessing. Result would be a new repository with a documentation somewhere that starts with enlisting into LLVM and finishes with running chapter one of tutorial.