# Becoming more of an OSS project

Here, I'd like to present and discuss some alternatives to the Shield initiative we currently have in FluentUI repo, that I believe would scale better and hopefully put the project on its way towards a more community-driven effort.

## 1. The Enarx project

Enarx is a security project striving to become the goto framework for easily injecting your program into a secure enclave (Intel SGX, AMD SEV, etc.). Enarx's approach to GitHub issues and PRs is as follows.

> First of, GitHub *is* the source of truth for the project - if it's not on GitHub, it means it doesn't exist.

When a new issue is submitted, bot puts the issue in the GitHub project's board in the "Triage" column ([link to the project board](https://github.com/orgs/enarx/projects/3)). Nobody is assigned at this point yet. Every day, the team meets for 15 minutes to go over the project board and figure out whether the issues within the "Triage" column are deemed valid or not. If yes, then they are put in the "Backlog". Then, the team decides if the issues get nominated to be worked on in the sprint or not. If so, they are put in the "Nominated" column. If the team member already has some preference, they can claim the issue for themselves by assigning it to themselves. Assigned issues end up in the "Assigned" column.

The project also features a dedicated project board for keeping track of issues assigned to the active sprint. See [this link](https://github.com/orgs/enarx/projects/2). This project board is more standard in the sense there are columns such as "Assigned", "Active", "Reviewing", "Reviewed", and "Done". The issue moves between the "Assigned", "Active" and "Done" columns, whereas the PR between "Reviewing", "Reviewed" and "Done" columns. The interesting thing to note here is that the PR gets auto-assigned to either the reviewer or the author depending on whether a code review is needed, or the author should address the feedback. While this might be an overkill early in the project, it comes in handy later on for properly routing the notifications to the appropriate persons.

The important thing about this approach is that it promotes team work but it also fosters better community engagement since the members of the wider community can and are assigned to different issues. Assigning the issues to members of the community and especially newcomers, requires a certain does of mentorship from the savvy members of the team/community however.

## 2. The Wasmtime project by the Bytecode Alliance

This is the project that effectively launched WASI (or WebAssembly System Interface) into existence, and was started by folks of Mozilla Research. This project doesn't have project boards on GitHub nor Shield-like mechanism. Instead, the maintainers and contributors answer/solve the issues from their own volition. This approach since it's not very well structured requires a dose of discipline to remember to check on the issue tracker regularly and see if there's something that can be solved immediately or triaged, etc.

The good: after some time, when everyone gets the hang of it, this approach becomes second nature and issues will get solved at a steady pace and won't pile up.

The bad: this approach requires both the maintainers/contributors *and* the issue submitters to be responsive. **NOTE:** I noticed in FluentUI repo that the latter is usually not the case unless one of the maintainers submitted an issue which is a bit worrying, as if the submitter doesn't care about the issue getting fixed, and worse, they don't want to contribute a patch. I think persuading the issue submitter to actually submit a patch is very beneficial to the project and something we should strive for. It does require the maintainers to be willing to offer some mentoring however.

## 3. The Zig language project

Finally, the Zig lang project is a YAC or yet-another-compiler project: Zig being here a new systems programming oriented language. Zig takes a similar approach to the Wasmtime project described above, and tries to persuade the issue submitters to contribute to the project by actually trying to tackle the issue themselves. After some time, when contributors spend enough time digging in several places, they naturally become eligible to weigh in and even perform code review, to finally become promoted to the role of a maintainer/collaborator.

## 4. React project

TODO: could anyone with more experience in this area write some words about their approach perhaps?

# Our goals

* community engagement: issues + attempts at patches/fixes
* better mentoring
* having code that is usable in a variety of settings - if you want to conform to MS UI, you use FluentUI
* FluentUI as a great example codebase - leading by example; this is particularly valid when it comes to ARIA, accessibility and OpenUI
* expertise in inner workings of HTML, CSS, JS, TS, React projected to the community
* simple DX means easier contributing means more contributors - [example](https://reactjs.org/docs/how-to-contribute.html)
* more transparency - everything on GitHub
* unification of tools: no HackMD for project mgmt
* use GitHub Project boards

**Question:** can outside contributors become core team members?

**Question:** do we tend to contribute to outside OSS projects?

# Blockers

* changing work culture - from closed source to open source
* timezones!
* OSS is a lot of work...mentoring, curating, maintaining...
* OSS means you have to communicate in writing...a lot...