-
Notifications
You must be signed in to change notification settings - Fork 1
Contributor access
For people who make the occasional contribution to Flutter (filing an issue, submitting the occasional PR, chatting on Discord), the default set of permissions is fine. However, if you are a frequent contributor, whether helping us in triage, or often fixing bugs, or regularly improving our documentation, or regularly helping others in our #help channel, you may find your life is more pleasant with commit access (also know as "contributor access", "being a member of the flutter-hackers group", "being a member of the Flutter team").
We grant commit access (which includes full rights to the issue database, such as being able to edit labels) to people who have gained our trust and demonstrated a commitment to Flutter.
Specifically, if you meet one of the following criteria and you have a sponsor (someone who already has contributor access and agrees that you should be granted access), then please ask your sponsor to propose, on the #server-support chat channel, that you be made a member of the team, and then reply to that message explaining which criteria below you are claiming to meet. The possible criteria are:
- You have recently submitted several PRs that have landed successfully (received an LGTM, PR was merged, no regressions reported, PR was not reverted), without needing extensive tutoring in the process.
- You have a long history of participating productively in our chat channels, helping with Triage, helping other contributors track down problems, finding meaningful issues in submitted PRs, and helping people in our #chat channel, all while demonstrating exemplary behavior that closely aligns with our code of conduct.
- You are employed by a company with a history of contributing to Flutter, for the purpose of yourself regularly contributing to Flutter.
- You represent a development team that creates applications, plugins, or packages using Flutter and have a close relationship with our developer relations team, including having a customer label, and have a great need to regularly update labels on issues (see Issue hygiene, Customers). (This is rare.)
Being granted access means that you will be added to the "flutter-hackers" group on GitHub and the "team" role on Discord. This privilege is granted with some expectation of responsibility: contributors are people who care about Flutter and want to help Flutter along our roadmap. A contributor is not just someone who can make changes or comment on issues, but someone who has demonstrated their ability to collaborate with the team, get the most knowledgeable people to review code, contribute high-quality code, follow through to fix bugs (in code or tests), and provide meaningful insights on issues.
We grant access optimistically based on a reasonably small volume of evidence of good faith. Correspondingly, we will remove access quickly if we find our trust has been violated. Contributors with commit access must still follow all our processes and policies, and must follow our code of conduct rigorously. (Please read it, it's stricter than most.)
If you have commit access or "team" access on the Discord server, you are responsible for enforcing our code of conduct.
Our code of conduct is much, much stricter than most. We do not wait until someone has been actively rude or insulting. Being disrespectful in any way is grounds for action. For example, passive-aggressive whining and general unconstructive negativity are all violations of the code of conduct. If someone is in a bad mood, we would rather they avoided contributing to Flutter on that day.
When you see something that might be described as unwelcoming or is in some other way a violation of our code of conduct, promptly contact the offender and ask them to read the code of conduct and consider how they might more effectively espouse its philosophy. Most people react very positively to this.
If they react negatively, or if they continue to make the environment unpleasant, they should be removed from the environment. On Discord, this would be kicking them from the channel. Repeat offenders should be banned. On GitHub, they can be blocked from our organisation (you may need to ask ianh@ or another admin of our GitHub org to do this). Please let the #server-support chat channel know when you do anything like this, so that we can keep an eye on how common it is.
Being in the GitHub "flutter-hackers" group gives you the following:
-
The ability to merge your own PRs once they are reviewed (see Tree Hygiene).
-
The ability to add labels, milestones, etc, on issues on GitHub (see Issue Hygiene).
-
PRs will run their tests slightly faster.
Being in the Discord "team" group gives you the following:
-
The ability to talk without rate-limiting on the #hackers-* channels.
-
The ability to kick people.
-
The ability to manage the server emoji.
The actual process (as followed by Flutter repo admins) is as follows:
- Verify the identity of the person making the request.
- Verify that they qualify under all the terms described above. If you know them, you can be their sponsor, otherwise, make sure they have one.
- Click the "Add a member" button on the flutter-hackers team page on GitHub.
- Type their name in the text field, select them, then click the "Invite" button.
- If they are on Discord, add them to the "team" group there too. Be sure to verify that you are promoting the right person; multiple people can have the same nickname on Discord!
- Home of the Wiki
- Roadmap
- API Reference (stable)
- API Reference (master)
- Glossary
- Contributor Guide
- Chat on Discord
- Code of Conduct
- Issue triage reports
- Our Values
- Tree hygiene
- Issue hygiene and Triage
- Style guide for Flutter repo
- Project teams
- Contributor access
- What should I work on?
- Running and writing tests
- Release process
- Rolling Dart
- Manual Engine Roll with Breaking Commits
- Updating Material Design Fonts & Icons
- Postmortems
- Setting up the Framework development environment
- The Framework architecture
- The flutter tool
- API Docs code block generation
- Running examples
- Using the Dart analyzer
- The flutter run variants
- Test coverage for package:flutter
- Writing a golden-file test for package:flutter
- Setting up the Engine development environment
- Compiling the engine
- Debugging the engine
- Using Sanitizers with the Flutter Engine
- Testing the engine
- The Engine architecture
- Flutter's modes
- Engine disk footprint
- Comparing AOT Snapshot Sizes
- Custom Flutter engine embedders
- Custom Flutter Engine Embedding in AOT Mode
- Flutter engine operation in AOT Mode
- Engine-specific Service Protocol extensions
- Crashes
- Supporting legacy platforms
- Metal on iOS FAQ
- Engine Clang Tidy Linter
- Why we have a separate engine repo
- Reduce Flutter engine size with MLGO
- Setting up the Plugins development environment
- Setting up the Packages development environment
- Plugins and Packages repository structure
- Plugin Tests
- Contributing to Plugins and Packages
- Releasing a Plugin or Package
- Unexpected Plugins and Packages failures