Skip to content
This repository has been archived by the owner on May 4, 2022. It is now read-only.

Latest commit

 

History

History
84 lines (51 loc) · 5.3 KB

committers.md

File metadata and controls

84 lines (51 loc) · 5.3 KB
Raw

Project committers

Who are the committers?

  • Christian Murphy ( @ChristianMurphy )
  • Paulina Nogal ( @nogalpaulina )
  • Andrew Petro ( @apetro )
  • Doug Reed ( @Doug-Reed )
  • Dave Sibley ( @davidmsibley )
  • Tim Vertein ( @vertein )
  • Zeke Witter ( @thevoiceofzeke )

What's a Committer?

Committers are stewards of the project.

Committership is a state of mind. Committers are Committers because the other Committers recognize them as Committers and because they recognize themselves as (and act like) Committers.

Committership is not access to write changes. Committers are entitled to write access and other like infrastructural privileges, but "write access" isn't the point, it's just a tool. You aren't a Committer because you have write access; you might have write access because you're a Committer.

How do I become a Committer?

Committership is a state of mind. Of your mind, and of the minds of the other Committers. You become a Committer because the other committers recognize you as a Committer and because you recognize yourself as (and act like) a Committer.

Formally, you become a Committer when the other Committers acknowledge this state of mind by formal nomination and vote on the email list.

What happens to inactive Committers?

Committership is for life. If you once acted as a steward of the project, you could almost certainly get back into that state of mind.

Inactive committers tend to lose access privileges, through entropy and through minimizing unneeded security exposure. This doesn't mean Committers stop being Committers - it just means they may need infrastructure to be fixed up if and when they are again active.

Inactive committers may be characterized as "emeriti" by request or by vote of the Committers. This is a convenient label for managing expectations about who is likely to be active. Votes that have heard from all active Committers need not wait for emeriti, for instance. Committers emeriti will be restored as regular Committers upon request.

Rules?

We adopt the rules and culture of the Apache Software Foundation.

We make necessary or pragmatic local adaptations.

  • Committers form the "PMC" for purposes of Apache rules.
  • We use the lists we have. Currently, the go-to list is public [email protected]. If we had more differentiated lists we'd use them in the way an Apache project would use them.

Governance fail safe: the uPortal Steering Committee

This is a (presently, incubating) Apereo uPortal ecosystem project.

The uPortal Steering Committee or successor governance body may at any time for any reason arbitrarily change the Committer roster of this project.

This is a fail-safe. If it has to be invoked, it's because something failed.

Governance fail safe: the freedom to fork

This is an open source project under the Apache 2 open source software license.

Like all open source projects, the ultimate fail-safe is the freedom to fork. Anyone can adopt this source code, re-plant it somewhere else, and re-bootstrap a living, breathing project around it.

Anyone can do that. But they probably shouldn't. Preferable to engage here instead.

Mechanics

To add a committer

  1. Validate that the would-be committer appears in the public registry of Apereo ICLA signatories.
  2. Informally privately check with existing Committers to preview support for the committer add proposal. Resolve any skeletons in closets or other issues that seem to benefit more from privacy than they would from resolution in the open. Strike balances between avoiding embarrassment and openness.
  3. Informally privately check with the would-be Committer to validate desire and availability to become a committer.
  4. Publicly propose on uportal-dev@ that the new committer be added. This proposal should include a summary of some of the merit of the proposed committer -- whatever rationale is justifying adding them. The proposer should immediately +1, helping to emphasize that this is a vote. This is a consensus vote: requires 3 +1s with no binding vetoes. The vote runs for a week or until all active Committers have voted.
  5. Summarize the votes and result in a wrap-up post to the thread.
  6. Issue a Pull Request adding the new committer to COMMITTERS.md, linking the email thread documenting the vote supporting the add. Secure a +1 from another committer verifying correctness. Merge the Pull Request. If merging in a way that does not preserve individual commits and their commmit messages, ensure e.g. the squash commit message itself links the email thread documenting the successful vote.
  7. Add the new Committer to the uPortal-application-framework Committers GitHub Team

References

Apache Software Foundation on