Conversation
… are a subset of users.
maintainer from outside WMKO.
| All maintainers implicitly agree to abide by the mKTL code of conduct. | ||
|
|
||
|
|
||
| Communication |
There was a problem hiding this comment.
Pulling this over from Slack -
We're also missing a section for work intake and prioritization, meaning how work gets chosen in the first place
I think some areas I'd like to add to this --
Work items in mKTL may originate from multiple sources
- Bug reports submitted via GitHub issues
- Operational needs identified by WMKO
- Feature requests from users or contributors
Maintainers are responsible for triaging incoming issues
- Confirming the validity of a bug or request
- Closing issues that are out of scope or not actionable
What does prioritization mean?
What does Selection for development mean?
There was a problem hiding this comment.
I feel like if we go that route we are inviting a full Kanban board approach, and I don't know if that's strictly necessary. I'm happy to let things be brought up in a conversational context and we go from there; if that proves unworkable I'm happy to revisit the question.
| much time a contributor might provide to the project. | ||
|
|
||
| All contributors implicitly agree to abide by the mKTL code of conduct. | ||
|
|
There was a problem hiding this comment.
Contributor status alone does not confer approval authority under this
policy. Binding approvals are provided only by maintainers.
| repository. There will always be an odd number of designated maintainers | ||
| to ensure a majority vote is possible, should voting situations arise. | ||
| The minimum number of maintainers is one. | ||
|
|
There was a problem hiding this comment.
There shall at all times be at least one designated maintainer from each
of the following participating institutions: W. M. Keck Observatory
(WMKO), University of California Observatories (UCO), and the California
Institute of Technology (Caltech). Additional maintainers may be added
as needed. The total number of maintainers need not be odd.
There was a problem hiding this comment.
If the number of maintainers is allowed to be even, is a 50% vote considered a deadlock, or is that an approval?
| of the current maintainers. The initial set of maintainers is expected | ||
| to include representatives from W. M. Keck Observatory, University | ||
| of California Observatories, and the California Institute of Technology. | ||
|
|
There was a problem hiding this comment.
Any change to the list of maintainers, including addition, removal,
or change in institutional affiliation, must be approved by at least one
maintainer from each participating institution. The last maintainer seat
for a participating institution may not be removed, left vacant, or
reassigned without that institution's affirmative approval. This
requirement is intended to preserve institutional veto authority.
| of California Observatories, and the California Institute of Technology. | ||
|
|
||
| All maintainers implicitly agree to abide by the mKTL code of conduct. | ||
|
|
There was a problem hiding this comment.
The initial set of maintainers shall include representatives from WMKO,
UCO, and Caltech.
| * major, for changes breaking backwards compatibility | ||
| * minor, for backwards-compatible additions or changes | ||
| * patch, for backwards-compatible bug fixes | ||
|
|
There was a problem hiding this comment.
Project support
WMKO may be the principal operational customer for many mKTL deployments.
That operational role does not alter the governance or approval rights
defined in this document.
WMKO, UCO, and Caltech are the participating institutions for purposes of
project governance. Each participating institution is expected to support
the participation of at least one maintainer for the duration of its
operational or development use of mKTL, and to internally support
contributors as needed for ongoing development and operational fixes.
There was a problem hiding this comment.
I'm fine with making the language stronger with respect to participation from UCO and Caltech, but I didn't want to commit resources on their behalf. If both organizations are on board with making that commitment we can revise the language.
ApprovalFor purposes of project governance, each participating institution holds This policy intentionally grants WMKO, UCO, and Caltech veto authority. Changes to mKTL governance require affirmative approval from at least one Approval of any other change to a protected branch, including code, Contributor feedback and review are strongly encouraged, but contributor Maintainers should avoid being the sole approving voice for their own No maintainer may bypass the institutional approval requirements. |
4 participants
This pull request adds a governance section to the official mKTL documentation. The contents are based on language from other resources, specifically:
https://opensource.guide/leadership-and-governance/
https://pypeit.readthedocs.io/en/stable/governance.html
The settings of the GitHub repository will be modified once the governance is accepted.