TianoCore Who we are
Rev 1.0
TianoCore is a community supporting open source implementation of the Unified Extensible Firmware Interface (UEFI). This community includes a mixture of professionals and volunteers from all over the world, working on every aspect of the mission - including mentorship, teaching, and connecting people. Our community enables UEFI firmware and tools through various open source projects. Most of our efforts are currently related to the EDK II project.
The community consists of Contributors, Maintainers, Reviewers, Stewards, Community Manager, Release Manager, and TianoCore Admin. All members adhere to the Tianocore.org Code of Conduct.
Technical development community includes Stewards and Maintainers to steer the technical direction of EDK II project hosted on Tianocore.org.
The technical development community will be assisted by the Stewards. Current Stewards body includes technologists from Apple Inc., Intel Corporation, NUVIA Inc, and Red Hat, Inc., representing diverse areas to maintain a healthy ecosystem.
A Contributor is anyone with interest in contributing to Tianocore.org
-
Follow the process rules for code contributions to any of the EDK II Projects on Tianocore.org such as:
-
Post patches to edk2-devel
-
Ask questions (edk2-discuss, edk2-rfc, edk2-devel)
-
File bugs (TianoCore Bugzilla)
-
Test and review patches for others as defined in the process rules
-
Author or correct wiki articles
-
Create a Github account: https://github.com/
-
Join the EDK II Project Mailing list: Mailing List
-
Follow the guidelines for submitting a code contribution by the EDK II Project Code Contributions process: https://github.com/tianocore/tianocore.github.io/wiki/Code-Contributions
A Maintainer manages one or more packages from the EDK II project of Tianocore.org.
Every EDK II package (top-level directory) has a list of maintainers. The role of a maintainer is to:
-
Maintainer assignments to packages and source file name patterns are provided in the "Maintainers.txt" file.
-
Subscribe to the "edk2-bugs" mailing list https://edk2.groups.io/g/bugs, which propagates TianoCore Bugzilla https://bugzilla.tianocore.org/ actions via email. Keep a close eye on new issues reported for their assigned packages. Participate in triaging and analyzing bugs filed for their assigned packages.
-
Responsible for answering questions from contributors, on the edk2-devel mailing list https://edk2.groups.io/g/devel/ and reviewing pull requests for their assigned packages.
-
Responsible for coordinating pull request review with co-maintainers and reviewers of the same package.
-
Has push / merge access to the merge branch.
-
Responsible for merging approved pull requests into the master branch.
-
Follow the EDK II development process.
Guidelines for a Maintainer
-
Process review requests in FIFO order.
-
Maintainer is responsible for timely responses on emails addressed to them (preferably less than calendar week).
-
If you are out-of-office for an extended period of time, inform the Stewards and/or your co-maintainers about pending requests. Use automated out-of-office replies to indicate your return date, if you feel comfortable sharing that info. You can also update your GitHub status to indicate you are out-of-office.
-
Try to let each patch sit on the list for at least 24h before merging it, so that other community members can comment on the patch.
Adding a Maintainer
-
A Contributor proposes a patch for Maintainers.txt, extending the section for the subsystem / package in question, with a new "M:" line.
-
An existing maintainer of the package approves the new Maintainer.
-
One of the stewards or one of the existing maintainers of the package merges the pull request containing the change.
-
TianoCore admin will update the permissions for the new maintainer with access rights to merge and push updates to the appropriate repo on TianoCore.
Removing a Maintainer
-
The maintainer who wishes to leave will propose their own removal in a patch for Maintainers.txt.
-
Optimally, this pull request should be posted from the GitHub account which the leaving maintainer is currently represented in Maintainers.txt. The email address used for the git author should ideally be from the currently represented email in Maintainers.txt -- for example, preferably from the "old company address", and not the "new company address". Giving up a maintainership, if it was associated with someone's job, should preferably be part of the exit procedure from that particular job.
-
The remaining co-maintainer(s) for the same package acknowledge and merge the patch. If no maintainer is left for the subsystem, stewards may help with the merging.
-
TianoCore admin will update permissions and remove access rights.
A Reviewer is anyone with interest in contributing to Tianocore.org
-
Reviewers help maintainers review code, but don't have push access.
-
A designated Package Reviewer:
-
shall be reasonably familiar with the Package (or some modules thereof)
-
will be copied on the pull request and mailing list discussions,
-
and/or provides testing or regression testing for the Package (or some modules thereof), in certain platforms and environments.
-
Reviewer is responsible for timely responses on emails addressed to them (preferably less than calendar week).
-
Same rules apply from the Contributors.
-
Steward is an active community member that helps steer the TianoCore project and helps drive the community to reach consensus.
-
The role of a steward is to influence and enact policies and define direction of TianoCore projects.
-
The Stewards meet regularly to discuss the EDK II project.
-
Identify and analyze issues in collaboration, communication, and workflow; help the community reach consensus to drive a decision.
-
Stewards are responsible for long term planning & infrastructure of the EDK II project.
-
Stewards guide the relationship of the TianoCore project with the projects that TianoCore depends upon.
-
Stewards guide the relationship of TianoCore project with downstream consumers and encourage them to contribute back to the EDK II project.
-
Promote open source development practices on the edk2-devel mailing list
-
Uphold the code of conduct; speak up if someone violates it on the list or other collaboration areas.
-
Evaluate exceptions to established processes. Evaluate conscious divergences from, or evolution of, current processes. For example, this covers the eligibility of patches for merging during the feature freezes, or more sweeping model changes such as "git forge" evaluation / adoption.
-
Stewards are responsible for maintaining "Maintainers.txt", and reviewing patches submitted for "Maintainers.txt".
Stewards loosely distribute the above responsibilities between each other; not every steward is active in every role. Activities and interests shift with time too.
New stewards are elected by existing stewards in recognition of work already being done.
If one of the Stewards decides to retire, they can resign simply by sending a patch to modify Maintainers.txt. The remaining Stewards may elect a new Steward to cover the gaps to maintain a healthy ecosystem.
A TianoCore Admin manages the access rights to TianoCore Community.
- The TianoCore admin is responsible for monitoring role changes in the community such as managing access rights while adding/removing maintainers.
- Responsible for Approval and removal of access to TianoCore resources such as GitHub, Bugzilla, groups.io etc..
A Release Manager manages the TianoCore releases to the Community.
The Release Manager is responsible for driving the quarterly Stable Tags. The Release Manager will plan the features, schedule the release date, create the Stable Tag with the release notes and announce to the EDK II community on the release milestones: Soft feature freeze, hard feature freeze and the final release of the Stable Tag.
A Community Manager manages the TianoCore Community.
-
Responsible for chairing TianoCore community meetings.
-
Management of community issues.
-
Coordinate community outreach activities.
-
Run the TianoCore community meetings on a regular basis.
-
Use a mail user agent that supports a "threaded view" and supports tagging messages for later.
-
Process messages / backlog in rough FIFO order.
-
Keep an eye on your mailbox, do revisit tagged messages.
- Use the GitHub interface to create and review pull requests.
-
Writing bug reports, issues and/or feature requests:
-
Capture all relevant details such as log files, screenshots, command lines, product names, specific product / use case details etc.
-
Provide minimal reproducers.
-
Always include where the bug is reported (e.g. EDK II commit, tree and/or branch).
-
Frame your bug report / feature request in terms of "actual results" vs "expected results".
-
-
Responding to new or existing bug reports:
-
Coordinate work with others
-
If the issue is an embargoed security issue, share & discuss with your own (downstream) un-embargo deadlines or other constraints.
-
Capture posted patches / patch versions in Bugzilla comments and link to the mailing list archive.
-
Manage Bugzilla metadata for the fields: assignee, package, status etc. and manage the dependencies diligently.
-
Identify duplicate bugs, use the matching Bugzilla resolution.
-
Close Bugzilla ticket once fixed, or feature is complete. Record subject commit range in Git history in a new Bugzilla comment.
-
List new feature Bugzillas and high-profile bug fixes here.
-
Resources
https://wiki.openstack.org/wiki/Open
https://en.wikipedia.org/wiki/Open_source#The_open-source_model_and_open_collaboration
Links: About TianoCore| Licensing| FAQ | How to Contribute | Code of Conduct | Wiki