# Office Hours round table notes

Community US Developer Meeting
1

Thank you @cishida, @AaronBallman, @tstellar, @erichkeane for actively participating and creating ideas and inputs.

We observered that the availability of “office hours” sessions remains not very widely known. We need to continue widely advertizing their existence. In particular, newcomers mostly don’t seem to know about their existence. We thought of the following ways to advertize them more:

We observed that different hosts have different styles of office hours.
Office hours hosted by maintainers seem to mostly be a way to have access to a maintainer.
@kbeyls’s experience as a non-maintainer host is that he mostly gets newcomers joining who are looking for ways to get started in llvm. Many of them are looking for a “good first issue” to get started on. The experience of searching for an appropriate good first issue together with a newcomer makes Kristof believe that most issues labeled as “good first issues” are actually not very good first issues. Most such issues require too much deep expertise to get started, and the learning curve before becoming productive is too steep.

At the round table, we speculated that some of the reasons it’s hard to maintain a good set of “good first issues” are the following:

  • For most experienced developers when encountering an easy-to-fix issue, it’s easier to just go and fix it, rather than create an issue with a really good description of the issue.
  • The few actually good, easy-for-a-beginner-to-fix issues, are in short supply. The few that are get picked up quickly and fixed. This results in an even fewer actually-good first issues.

We explored ideas on how we could improve the experience of newcomers looking for good first issues that help them get started in the project. Ideas we came up with are the following:

  • It would be great if “good first issues” also explicitly mentioned one or a few potential mentors for the work. [pre-existing community.o issue for this]
  • We thought that rather than trying to maintaining a fully curated list of good first issues, it might be more effective to also have a few “meta” issues that document how to find issues yourself that are probably good beginner issues. We thought the following might be good sources for people to find good first issues themselves:
    • Fixing warnings produced by static analyzers with low false positive rates. @tstellar mentions that github has specific checks (@tstellar: Do I remember this correctly? If so, do you have a pointer?)
    • Writing tests to increase code coverage could also be a good source for good beginner issues. How could newcomers prioritize which areas with low code coverage are most impactful to focus on?
    • (Kristof after the round table finds that there is a community.o issue already for "Encourage newcomers to create PRs with updated documentation when it’s missing for them)

We thought that it would be good to make “meta” “good first issues” for these and similar sources of good first issues, and make them sticky at the top of the good first issue list, so that they are easily found. [new community.o issue for this]
We could/should add links to office hours hosts in these sticky issues and/or add pointers to other available mentors.

If you’re interested in helping out implementing some of these ideas, or with further improving the ideas themselves, please use the community.o issues that are pointed to, or discuss further on this thread.

In an attempt “to advertize more widely”, I also made a short LinkedIn post about this. Liking/reposting it might help with spreading the message.

3 Likes
2

Thanks for putting this together! I’ve decided I’m going to try participating in Aaron’s office hours as much as I can. If I can participate regularly, we might convert this to a “CFE Maintainers” office hours, but we’ll have to see how my dedication is.

3 Likes
3

I’ve been trying to advertise them in LLVM Weekly for quite some time, but perhaps it’s not very widely read by those new to LLVM.

This is really interesting - I would have assumed the problem wasn’t so much knowing office hours exist, as being intimidated about joining. To that end, I’d wondered about some kind “what you can expect from office hours” that reflects that although different hosts might handle them in different ways but gives a little more colour beyond what is on the website already.

Thanks for writing up and sharing the notes!

1 Like
4

Thank you for advertising them in LLVM weekly! My guess it’s the best “advertising channel” office hours have :slight_smile:
It just seems when talking with people that are relatively new to the project, many don’t know that office hours exist. So, we could use more ways to advertise their existence.

There probably also is an issue with being intimidated about joining, and ideas to improve on that are very welcome :slight_smile: Would you like to create an issue in the community.o issue tracker to record your idea? If you’d prefer, I’m also more than happy to create the issue to keep track of this idea.

1 Like
5

This is the GitHub job that runs the static analyzer on main once per day:

1 Like
6

Speaking for clang frontend folks, good first issues are tough.

I think we are doing a decent job of labeling good first issues while we triage new issues but they get snapped up very quickly because we don’t have many of them. They normally don’t last a day :grimacing:

I would be hard pressed to come up with a good method for folks to go hunting for good first issues.

For clang frontend issues if someone does grab a new issue and they are having trouble getting help on the PR they can reach out on the clang discord channel. It can be tough because we have limited bandwidth at times e.g. when major WG21 meetings are coming up.

1 Like
7

Done! Consider saying more about how office hours work / give examples in order to make people feel less intimidated about joining · Issue #22 · llvm/Community.o · GitHub

1 Like