Upon recently learning that our Open Projects page 1) exists, and 2) hasn’t been updated since 2013, I spent some time cleaning it up to remove stale projects and add projects the community is already aware are areas we’re looking for help in. I’d like to hear if there are any other open projects that the community feels we should consider adding to the page.
This page is intended to give people ideas on how they can contribute when they first join the community and as a way to document what our needs are for the short- to medium-term in Clang at a very high level for our veteran contributors to understand the landscape of community needs. Each project listed on the page should have a concrete goal even if it is loosely defined and should be related to improving Clang in some way. The projects do not have to be specific to writing code for Clang (for example, documentation and QA tasks are perfectly appropriate to add). I think we should try to avoid advertising open projects for significant extensions to Clang or feature requests that should be filed in the issue tracker, and instead focus on core competencies at a high level (C, C++, Objective-C, significant refactoring projects, user experience).
Examples of ideas I think we could consider are:
Do we want a project for contributing an MLIR code generator to Clang?
Do we want a project to add a library for handling calling conventions and ABI decisions that sits between Clang and LLVM (instead of having these decisions spread between the two projects)?
Do we want a project to improve the build times of Clang itself so that we do not have such challenging system requirements for new contributors to the project?
What other ideas should we consider?
I plan to collect the ideas from this thread that seem to have significant support for them (if any) and propose additional patches to add them to the open projects page.
Sounds like a great idea. It’s interesting that we have clang related open projects for GSoC in the LLVM open project pages, perhaps we should link some of that somehow too?
Moving incrementally information about ABI into .e.g llvm/Frontend/TargetInfo would benefit many projects. Clang is kind of the ground truth in that area. The Flang people have constantly problems in that area and are copying code from Clang into Flang.
Improving compile time would also benefit many people.
I would really love some kind of tiny projects that newcomers could solve over the weekend.
That’s an interesting idea! There’s a tension between adding super short-term projects to that page and keeping the page from getting outdated. It’s pretty easy to forget to update this page as projects are completed (based entirely on the fact that this page was ignored for the better part of a decade). But at the same time, it would be kind of nice to split the page up by small, medium, and large projects so that newcomers have an idea as to how much work we think is involved in the work.
I wonder if there are good ways to maintain this page for short term projects beyond best-efforts of noticing it during review.
Agreed that we should ensure those two pages point to each other, at the very least. Good catch! Perhaps we could have the LLVM open projects page automagically include the content from the Clang page? Or do we want GSoC to be a separate set of open projects from the rest of the community open projects?
Maybe file these as issues with appropriate tags, and the page can have a link that does the right query. We’re not super good at keeping the issues up to date either, but there’s a better chance that a newcomer would pick up an issue and mark it resolved than that the page itself would get updated.
That seems like an excellent idea. I am not sure how we could organize this because for programs such as google summer of code we generally need one “landing” page for all open projects. I am not sure if we can somehow “link” the open projects for clang to the open projects for llvm. Certainly, we could do the opposite.
Adding @akorobeynikov as our GSoC admin who might have some insights.
I think we should mention Clang - C++ Defect Report Status explicitly, writing tests and updating the status of existing DRs is a worthwhile endeavor and a bit more specific and actionable than “increasing test coverage” as it is otherwise difficult for people to know what is or isn’t in need of tests
You’re right. Essentially for GSoC we need a single place where we can link all projects. This is both requirement of the program and also just makes sense to me – there should not be multiple unrelated pages and places.
So, cross-linking would probably be a good idea to start with.
I tried coming up with a reasonable string for linking to good first issues from the issues page, but GitHub’s search functionality is not sufficient to the task (that I’ve been able to find). The trouble is that we want to match a search string like: label:"good first issue" label: "clang\:?.*" so we’re getting good first issue matched with clang, or clang:diagnostics, or clang:frontend, etc. Because limiting to just clang as a label will not bring up very many issues (currently, only one issue). I’d rather not have to manually list the labels on the search because when we add new labels to GitHub, we won’t remember to come update this page accordingly.
If someone has ideas on how to work around this, I think it’s a great idea to add a link to good first issues from here. In the worst case, we could link to just issues with the good first issue label alone.
Thank you all for the good discussion and ideas! I’ve updated the Open Projects page based on feedback in this thread, except I’ve not added a link to good first issues or the GSoC projects due to the open questions. That said, I think those would be reasonable things to add if someone would like to propose a patch for them – feel free to add me as a reviewer!
The best I can think of is to have a bot that ensures the clang tag is added when clangf:foo is added to an issue.
But tbh, I’m not to worried about the prolifications of tags, having the full list in the query seems reasonable enough.
