[RFC] Helping the new contributors to create better contributions

Hello,

Over the past few months I noticed more contributions from people new to flang and to LLVM in general. Some of the contributions had seemingly common problems:

  1. Jumping straight into implementation without filing an issue first.
    In this case, a new contributor wants to fix a perceived problem in flang, but it may not be a real problem. When I see PRs like that, I ask the author to file an issue first so that it could be seen by more people and discussed. Some of the issues included perceived differences between behavior of flang and the other compilers or perceived deviations from Fortran standard. ( Fortran Extensions supported by Flang and Fortran intrinsic procedures would have been useful documents to read in some of such cases.)
  2. Jumping into implementation without sufficient design.
    Sometimes design is not discussed or perhaps not given time to be sufficiently “baked” and discussed. Closer following of Design Guideline — The Flang Compiler would be helpful in those cases.
  3. AI usage without following AI policy
    I have no problems with people using AI, but at the end of the day the new contributors need to understand the code being submitted. The contributions need to follow LLVM AI Tool Use Policy — LLVM 23.0.0git documentation . Also, this recent discussion is illuminating: RFC: Commit Access Criteria - #87 by vbvictor

Problematic contributions generate more demands on reviewer’s time and attention. I’d like to discuss possible ways we can encourage better contributions without alienating the contributors or overloading the maintainers.

Perhaps we could consider adding more documentation to Getting Involved — The Flang Compiler that would provide more specific guidance to the new contributors? Should we also investigate the possibility of “embracing” AI by creating CLAUDE.md/AGENT.md/WHATEVER.md with the instructions that would steer the AI agents in the right directions and provide more information/instructions to their users?

4 Likes

Thanks for the RFC.

Perhaps we could encourage the use of the slack server more, so if a first time contributor would like to discuss a design with the community (in a more light-weight way than a discourse RFC) then they do their best on their own and then post something thought through on slack for us to discuss. This shouldn’t replace discourse RFCs for bigger changes - I just wonder if it would be less intimidating for a first time contributor. Personally I wouldn’t mind a short slack conversation either on a channel or 1:1 if it is for a patch I would have ended up reviewing anyway. But we do need some care that this doesn’t become free design consultancy making maintainers busier, I think it is important that contributors try their hardest on their own first.

With regards to AI, I already use it myself and see a growing number of assist-by tags in Flang commits, including from experienced contributors. If anyone (especially long time contributors) has a high quality “WHATEVER.md” I would welcome that patch because it could help both existing contributors as well as those who are new.

Agreed. I assume that requiring an issue to be filed before working on something is a concrete suggestion that you would like to do. Is there anything else that you have in mind?

The developer policy explicitly states that we (maintainers) are allowed to ask if we suspect a contribution is primary AI-generated. It is a delicate issue, but perhaps we could be a bit more vocal if we suspect this to be the case?

I, personally, don’t see the difference between posting on Slack vs. Discourse, but maybe that is not how everyone sees it. One issue with Slack is that not everyone has access to the paid version, so older discussions may be out of reach. If we were to encourage this, I think we should make it clear that the discussion should be redirected to Discourse fairly quickly.

1 Like

I think it may be helpful to have a document about flang debugging capabilities that may be helpful when gathering information for new issues:

  • Unparse support
  • HLFIR and FIR dumps
  • flang defaults to -O0, whereas some compilers may default to -O1 or -O2 and this could lead to behavior differences when comparing compilers.