[RFC] Create a GitHub `Project` for MLIR

MLIR
1

This RFC proposes the creation of a GitHub Project for MLIR to:

  1. Track current major depreciations and refactorings. In this case, we would migrate Deprecations & Current Refactoring - MLIR to GitHub.
  2. Track open projects. In this case, we would migrate Open Projects - MLIR to GitHub.
  3. Track major new features in the works. This include dialects, infra upgrades, new major interfaces, …
  4. Track major issues that need attention.
  5. Track major RFCs and their approval.
  6. [Optional] Track the efforts proposed by the MLIR charter RFC, ie. what is the production status of each dialect, documentation efforts, and so on.

The idea is that this could help us organize communication upstream, and make it easier for everyone (including downstreams) to know what’s happening upstream.

The participation in the project, would be best effort. However, by putting it on GitHub we would increase accessibility to all users in the LLVM org to easily contribute and update tasks.

Hopefully, this would result in more visible deprecation or refactoring warnings, as it’s a bit less cumbersome than having to go through mlir-www.

I think for this to have some success, the organization should be fairly simple at the beginning, so here’s my initial proposal for a basic possible organization in the Project for the above items:

Depreciation proposal Depreciation PR Removal PR Feature removed
Remove feature x
Remove feature y
Remove feature z
Open project Assigned project Completed project
Project x
Feature proposal Feature upstreaming Completed feature
Feature x
Issue reported Issue in the works Issue fixed
Issue x
RFC proposed RFC denied RFC approved
RFC x

I won’t propose an organization for 6, and will leave it to the MLIR charter proponents to establish one that suits their needs.

@mlir-area-team

2

I have tried this a few times in other projects, with mixed success. I’d like these efforts to work better than they actually do in practice. In my experience, these efforts tend to die out with lack of updates the same way things in mlir-www and related places do.

If by “best effort” you mean the information there isn’t binding or required (ie. blocking upstream progress), then I don’t see any problem with it. Should be low cost to add this to Github, and if it gets unused, we can always discontinue.

IMO, if we use this as a “project management” platform, it may work fine. But if we try to replicate or replace the existing issue/forum platforms, it will have more bad outcomes than good ones. And it will need a wider discussion across the whole LLVM project, not just MLIR.

Some inline comments below:

These look simple enough to me, since not many people know the other two exist and they’re not easy to edit.

This is the core of projects, so I see this as a positive trend. But the discussion still must be done in the forum, as per policy. So, at most an organization that points to the issues and discussions in their respective places.

Not enough people pay attention to all the RFCs in the forum. If we move the discussion here, we’ll have even more places to look for and the risk of missing it will be higher. If this is the plan, it will need a wider discussion across the LLVM project and isn’t local to MLIR (change of policy).

This is a higher effort and misplaces the actual place we track them (issues, forum). It will either be full duplication (and IMO unnecessary) or segregation (and have the same problem above).

Side note: Different people/projects may have different interpretations of what “major” is.

I’d propose to link issues/discussions to the “features in the works” above instead of having them separate.

This looks like it’s already covered by 1, 2, 3 above. Or at least it’s close enough that could be bundled together.

3

Yes, that’s best effort.

Thanks for pointing this out explicitly, this RFC in no way proposes supplanting discourse. It’s only a project management tool. Important discussions should still happen on discourse or in PRs. Tasks (that require discourse discussion) should redirect to discourse.

The idea, is that users could see the project and the tasks and more easily discover what’s going upstream and discourse.

Re RFCs: The idea is to track consensus status of RFCs on github, making it easier to determine if it was approved or denied, rather having to parse 50+ comments in discourse to determine what happened.

Re Issues, that’s different from features on the works because it impacts existing components in MLIR. However, I do need to clarify what major is, but, I’m still working on a def. But to give you some examples, I’m increasingly convinced that region control-flow is broken in MLIR, and if I proved to be correct that’s a major issue, not a simple bug fix. Another example is: properties are broken for all bindings [mlir][python] Op properties are broken for python · Issue #150009 · llvm/llvm-project · GitHub

4

Great, +1 to that!

This is a lot of work! :sweat_smile:

I think it’s commendable if anyone has time to track it. But it could be valuable if we record consensus as they are resolved by the proper channels (natural or through escalation procedures).

Not what you propose, but there is a risk of “rushing” consensus through this tool. I don’t think we need to worry much, as we already have the process in place to remediate in case it does happen. But in case it happens often, the noise will become a problem. Hopefully it will converge to expected usage in time.

I’m just making the point of not duplicating issues into features, and it would be easy to group issues by linking them from a feature. In the past, we used to have meta issues in bugzilla, where other issues were linked to a common larger scope change / need. For example when we were fixing the inline assembler, or android / kernel support, or the mega-chromium bug.

IIUC, you want these features to act like project planning, which is similar to the meta bugs we had.

Agree! I think best is to play it by ear and not have a formal definition of what “major” is. I was just reminding us that people / projects have different views of MLIR and we don’t want that project infra to be a place of unnecessary disagreement.

1 Like
5

Thanks for bringing this up!

I strongly agree that we currently lack a good mechanism to track more involved efforts in MLIR development.

Some PRs that are part of a broader refactoring effort would be much easier to review, reason about, and track if there was a common point of reference. To me, that reference could be a GitHub issue (*) that captures the full context and can be tracked through a GitHub project.

Here are two recent examples of GitHub issues I created to track multi-PR efforts:

I emphasize GitHub issues because I believe GitHub projects are only truly valuable after we establish good issue hygiene. In particular, I feel that too many design discussions currently happen inside PRs - we’re not fully leveraging what GitHub provides for collaboration and tracking.

Regarding GitHub projects, I think it makes sense to adopt them - provided that the community is on board and uses them consistently. If only some information is tracked there, the value quickly diminishes. I’d be happy to use projects if there’s shared commitment.

– Andrzej

(*) Sometimes folks use links to Discourse threads, but those tend to be too high-level in my opinion. It can be hard to extract clear consensus from lengthy discussions.

2 Likes
6

I have tried to create Projects in the lighthouse repo, as a trial for @fabianmc’s proposal, and I see that they’re created private by default:

image
image346×421 18.9 KB

Then I tried to make them public and got this message:

image
image625×161 8.57 KB

I’m wondering if we can allow repo owners to do that, or create them as public in the first place. I don’t know what would be a case to create a private project in the upstream LLVM org anyway.

Everyone else just sees 404 page for the project:

https://github.com/orgs/llvm/projects/43

1 Like