From 6cb6ae56f16ee74ca127861879f97f3e6cbcb6ef Mon Sep 17 00:00:00 2001 From: Kyle Lanclos Date: Thu, 12 Mar 2026 11:57:38 -1000 Subject: [PATCH 01/19] Add a section on governance. --- doc/governance.rst | 83 ++++++++++++++++++++++++++++++++++++++++++++++ doc/index.rst | 1 + 2 files changed, 84 insertions(+) create mode 100644 doc/governance.rst diff --git a/doc/governance.rst b/doc/governance.rst new file mode 100644 index 00000000..f5b6b5b3 --- /dev/null +++ b/doc/governance.rst @@ -0,0 +1,83 @@ +Governance +========== + +This page describes the governance policy for mKTL. Any individual or +organization contributing to mKTL, regardless of their role, implicitly +agrees to this policy. + +Roles +----- + +User +^^^^ + +A user is anyone that uses mKTL for any task. This is the most important +role; a project with no users has no purpose. Users are encouraged to +provide feedback on any and all topics, especially with regard to any +strengths or weaknesses of mKTL from their perspective. + +Contributor +^^^^^^^^^^^ + +A contributor is anyone who manipulates the source code repository in +any context: submitting issues, commenting on issues, submitting pull +requests, or any similar activity is considered a contributor. Beyond +basic professional decency there are no expectations or commitments +associated with being a contributor, nor are there any limits on how +much time a contributor might provide to the project. + +Maintainer +^^^^^^^^^^ + +A maintainer is an individual with commit and merge access on the mKTL +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. + +Maintainers are expected to make routine contributions to mKTL, in the +form of reviewing and merging pull requests, actively participating in +discussions, and building consensus around any decisions. On an annual +basis this is expected to be a minimum of a 40-80 hour time commitment +from each maintainer. + + +Project support +--------------- + +The principal customer for mKTL and mKTL-based systems is +`W. M. Keck Observatory `_ (WMKO). As such, +WMKO is committed to the ongoing development and maintenance of mKTL, and +will support the participation of at least one maintainer for the duration +of mKTL's operational use, and will support contributors as needed for +ongoing development and operational fixes. + +Other participating institutions should make a similar commitment commensurate +with their needs. + + +User support +------------ + +There is no dedicated system to provide mKTL support to end users; at the +present time, any potential users of the system have direct contact information +for one or more maintainers; when such questions arise, contributions should +be made to address any deficiencies in the online documentation. + +The existence of project support does not imply there is a warranty or other +resources that the user base is entitled to draw upon should problems arise. + + +Approval +-------- + +Approval of any changes requires: + + #. A minimum of one maintainer + #. A minimum of two contributors from WMKO + #. A minimum of one contributor from outside WMKO + +There can be overlap between these roles, for example, if a maintainer is +from an external institution. Contributors are not expected to approve their +own contributions, except in the case where no other approvals are available, +for example if there is only one maintainer and their contribution that +requires approval. diff --git a/doc/index.rst b/doc/index.rst index b079a9a2..a1390495 100644 --- a/doc/index.rst +++ b/doc/index.rst @@ -35,6 +35,7 @@ be expert mKTL maintainers in order to successfully develop an application. configuration protocol protocol_interface + governance glossary Indices and tables From e30b2a7e92b21bf7aec88640ddd0b34ef459134e Mon Sep 17 00:00:00 2001 From: Kyle Lanclos Date: Thu, 12 Mar 2026 12:59:32 -1000 Subject: [PATCH 02/19] Tweak to the tail end of the approval language. --- doc/governance.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/doc/governance.rst b/doc/governance.rst index f5b6b5b3..a0e013d8 100644 --- a/doc/governance.rst +++ b/doc/governance.rst @@ -79,5 +79,6 @@ Approval of any changes requires: There can be overlap between these roles, for example, if a maintainer is from an external institution. Contributors are not expected to approve their own contributions, except in the case where no other approvals are available, -for example if there is only one maintainer and their contribution that -requires approval. +for example if there is only one maintainer and their contribution requires +approval. Maintainers have the authority to bypass the normal approval process +but this authority should be used sparingly, if at all. From 2644da52c4499523b7fdea6cf2893620245c9b2d Mon Sep 17 00:00:00 2001 From: Kyle Lanclos Date: Thu, 12 Mar 2026 13:47:09 -1000 Subject: [PATCH 03/19] Language about changes to governance. --- doc/governance.rst | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/doc/governance.rst b/doc/governance.rst index a0e013d8..dd7ba8f0 100644 --- a/doc/governance.rst +++ b/doc/governance.rst @@ -70,7 +70,11 @@ resources that the user base is entitled to draw upon should problems arise. Approval -------- -Approval of any changes requires: +Changes to the governance requires a full consensus among all maintainers, +and ideally a consensus from participating contributors. Significant changes +may also require the approval from supporting institutions. + +Approval of any other changes requires: #. A minimum of one maintainer #. A minimum of two contributors from WMKO From ea723d9a4ad9b115a5b3dc78f85f12206ade55b7 Mon Sep 17 00:00:00 2001 From: Kyle Lanclos Date: Thu, 12 Mar 2026 13:56:28 -1000 Subject: [PATCH 04/19] Ignore README.md, it's intended for consumption outside the documentation itself. --- doc/conf.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/conf.py b/doc/conf.py index 7fab7ecc..a3cefeda 100644 --- a/doc/conf.py +++ b/doc/conf.py @@ -18,7 +18,7 @@ extensions = ['myst_parser', 'sphinx.ext.autodoc', 'sphinx.ext.intersphinx'] templates_path = ['_templates'] -exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store'] +exclude_patterns = ['_build', 'README.md', '.DS_Store', 'Thumbs.db'] intersphinx_mapping = {'pint': ('https://pint.readthedocs.io/en/stable', None), 'python': ('https://docs.python.org/3', None)} From b06856624302725a6f15c80e50162b469db45c65 Mon Sep 17 00:00:00 2001 From: Kyle Lanclos Date: Thu, 12 Mar 2026 16:28:04 -1000 Subject: [PATCH 05/19] Add sections on communication and contributed code. --- doc/governance.rst | 49 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/doc/governance.rst b/doc/governance.rst index dd7ba8f0..6ada04ec 100644 --- a/doc/governance.rst +++ b/doc/governance.rst @@ -5,6 +5,7 @@ This page describes the governance policy for mKTL. Any individual or organization contributing to mKTL, regardless of their role, implicitly agrees to this policy. + Roles ----- @@ -41,6 +42,54 @@ basis this is expected to be a minimum of a 40-80 hour time commitment from each maintainer. +Communication +------------- + +mKTL is maintained as a GitHub project. Issue tracking will occur +via GitHub; discussion of pull requests should primarily occur in the +discussion thread associated with the pull request. Secondary discussions +will occur in the #mktl Slack channel in the WMKO Software Coordination +workspace. Side conversations are inevitable, but should be brought back to +a common space where all contributors can participate. + + +Contributed code +---------------- + +All code contributions will occur via pull request. Pull requests shall +be targeted and concise, ideally addressing a single topic (whether or +not it is separately filed as an issue), and being manageable to review. +The general rule of thumb is pull requests should take less than an hour +to review, as an upper bound; similarly, the number of lines changed +should be kept low, with 50-200 lines being a reasonable target, and 500 +lines as an upper bound. These are not firm requirements, but staying +within these guidelines helps reduce the burden on maintainers and other +reviewers. + +Informative commit messages and other inline documentation should be +leveraged whenever practical. Clear expressions of intent go a long way +towards understanding code, both for reviews and future debugging. + +Adherence to +`PEP-8 `_ is strongly suggested but +is not rigidly enforced; absent a document formally laying out the minutiae +of code style the established practices in existing code should be followed. +This includes handling of whitespace, quoting, capitalization practices, +variable naming, type hints (or the absence thereof), and the use of the +English language. + +Backwards compatibility is a priority for mKTL and all contributions should +take care to adhere to the established minimum package versions to the full +extent possible. Requiring a newer release of Python, for example, should be +a major topic of discussion among maintainers and contributors; use of +incompatible language features or module functionality will result in +rejection of a pull request. + +All contributors relinquish individual copyright claims for any contributed +code. Code subject to an external copyright should not be submitted in any +form. + + Project support --------------- From d54659a175b41295abaa978a2b789e7f8eaa3b34 Mon Sep 17 00:00:00 2001 From: Kyle Lanclos Date: Fri, 13 Mar 2026 09:20:31 -1000 Subject: [PATCH 06/19] Add mention of releases and the importance of the unit test suite. --- doc/governance.rst | 43 +++++++++++++++++++++++++++++++++++++++---- 1 file changed, 39 insertions(+), 4 deletions(-) diff --git a/doc/governance.rst b/doc/governance.rst index 6ada04ec..15f4f38b 100644 --- a/doc/governance.rst +++ b/doc/governance.rst @@ -56,6 +56,9 @@ a common space where all contributors can participate. Contributed code ---------------- +Pull requests +^^^^^^^^^^^^^ + All code contributions will occur via pull request. Pull requests shall be targeted and concise, ideally addressing a single topic (whether or not it is separately filed as an issue), and being manageable to review. @@ -64,32 +67,64 @@ to review, as an upper bound; similarly, the number of lines changed should be kept low, with 50-200 lines being a reasonable target, and 500 lines as an upper bound. These are not firm requirements, but staying within these guidelines helps reduce the burden on maintainers and other -reviewers. +reviewers, and increases the likelihood that a pull request can be properly +assessed and quickly merged. Informative commit messages and other inline documentation should be leveraged whenever practical. Clear expressions of intent go a long way towards understanding code, both for reviews and future debugging. +All pull requests are expected to pass the unit test suite with no errors. + +Code style +^^^^^^^^^^ + Adherence to `PEP-8 `_ is strongly suggested but is not rigidly enforced; absent a document formally laying out the minutiae -of code style the established practices in existing code should be followed. +of code style the established practices in the mKTL code should be followed. This includes handling of whitespace, quoting, capitalization practices, variable naming, type hints (or the absence thereof), and the use of the English language. +Compatibility +^^^^^^^^^^^^^ + Backwards compatibility is a priority for mKTL and all contributions should -take care to adhere to the established minimum package versions to the full -extent possible. Requiring a newer release of Python, for example, should be +take care to adhere to the established minimum package versions. +Requiring a newer release of Python, for example, should be a major topic of discussion among maintainers and contributors; use of incompatible language features or module functionality will result in rejection of a pull request. +Copyright +^^^^^^^^^ + All contributors relinquish individual copyright claims for any contributed code. Code subject to an external copyright should not be submitted in any form. +Releases +-------- + +Periodic stable releases will be tagged from the main repository; this should +be the resource of choice for any users requiring stable behavior. The main +branch makes no promises of stability, other than it is expected to be self +consistent and functional. Branches are intended for specific feature or +issue related development, and will not have any meaningful persistence. + +mKTL will follow the Python versioning scheme described in +`PEP-440 `_, though perhaps with more +clarity in the `Python packaging documentation `_ +as `semantic versioning `_, with a three part +version number, concatenated with a '.' character: + + * major, for incompatible API changes + * minor, for backwards-compatible additions or changes + * patch, for backwards-compatible bug fixes + + Project support --------------- From 07c6b6769b1a93f17ecb76298990ca2c46d10837 Mon Sep 17 00:00:00 2001 From: Kyle Lanclos Date: Fri, 13 Mar 2026 14:48:14 -1000 Subject: [PATCH 07/19] Speak to how maintainers are designated. --- doc/governance.rst | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/doc/governance.rst b/doc/governance.rst index 15f4f38b..fe76d267 100644 --- a/doc/governance.rst +++ b/doc/governance.rst @@ -41,6 +41,11 @@ discussions, and building consensus around any decisions. On an annual basis this is expected to be a minimum of a 40-80 hour time commitment from each maintainer. +Any changes to the list of maintainers must be approved by a majority +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. + Communication ------------- @@ -132,8 +137,8 @@ The principal customer for mKTL and mKTL-based systems is `W. M. Keck Observatory `_ (WMKO). As such, WMKO is committed to the ongoing development and maintenance of mKTL, and will support the participation of at least one maintainer for the duration -of mKTL's operational use, and will support contributors as needed for -ongoing development and operational fixes. +of mKTL's operational use, and will internally support contributors as needed +for ongoing development and operational fixes. Other participating institutions should make a similar commitment commensurate with their needs. From 0cde95ab41d3f183d7e22a4dd82d8b25b3ea4757 Mon Sep 17 00:00:00 2001 From: Kyle Lanclos Date: Fri, 13 Mar 2026 14:58:13 -1000 Subject: [PATCH 08/19] Minor clarity improvements. --- doc/governance.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/governance.rst b/doc/governance.rst index fe76d267..01f18e0e 100644 --- a/doc/governance.rst +++ b/doc/governance.rst @@ -86,8 +86,8 @@ Code style Adherence to `PEP-8 `_ is strongly suggested but -is not rigidly enforced; absent a document formally laying out the minutiae -of code style the established practices in the mKTL code should be followed. +is not rigidly enforced; absent a formal code style document +the established practices in the mKTL code should be followed. This includes handling of whitespace, quoting, capitalization practices, variable naming, type hints (or the absence thereof), and the use of the English language. @@ -159,7 +159,7 @@ resources that the user base is entitled to draw upon should problems arise. Approval -------- -Changes to the governance requires a full consensus among all maintainers, +Changes to mKTL governance require a full consensus among all maintainers, and ideally a consensus from participating contributors. Significant changes may also require the approval from supporting institutions. From cd1566cc1817e6f1ab6f2e62bb499022c7761542 Mon Sep 17 00:00:00 2001 From: Kyle Lanclos Date: Fri, 13 Mar 2026 16:53:42 -1000 Subject: [PATCH 09/19] Remove the undefined use of 'API'. --- doc/governance.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/governance.rst b/doc/governance.rst index 01f18e0e..cde8861b 100644 --- a/doc/governance.rst +++ b/doc/governance.rst @@ -125,7 +125,7 @@ clarity in the `Python packaging documentation `_, with a three part version number, concatenated with a '.' character: - * major, for incompatible API changes + * major, for changes breaking backwards compatibility * minor, for backwards-compatible additions or changes * patch, for backwards-compatible bug fixes From 289308b7754a3cb0670acf4fc0b17d53f7b77017 Mon Sep 17 00:00:00 2001 From: Kyle Lanclos Date: Mon, 16 Mar 2026 10:33:18 -1000 Subject: [PATCH 10/19] Add a line about how long the assessment of a pull request is expected to take. --- doc/governance.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/doc/governance.rst b/doc/governance.rst index cde8861b..ede5c637 100644 --- a/doc/governance.rst +++ b/doc/governance.rst @@ -73,7 +73,8 @@ should be kept low, with 50-200 lines being a reasonable target, and 500 lines as an upper bound. These are not firm requirements, but staying within these guidelines helps reduce the burden on maintainers and other reviewers, and increases the likelihood that a pull request can be properly -assessed and quickly merged. +assessed and quickly merged. This assessment process is expected to occur +within a week of submission. Informative commit messages and other inline documentation should be leveraged whenever practical. Clear expressions of intent go a long way From ba58be593ffefc3ba9c65538d73d3dc92a996d5d Mon Sep 17 00:00:00 2001 From: Kyle Lanclos Date: Wed, 18 Mar 2026 11:19:59 -1000 Subject: [PATCH 11/19] Make reference to the code of conduct. --- doc/governance.rst | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/doc/governance.rst b/doc/governance.rst index ede5c637..dd7cd1d8 100644 --- a/doc/governance.rst +++ b/doc/governance.rst @@ -27,6 +27,8 @@ basic professional decency there are no expectations or commitments associated with being a contributor, nor are there any limits on how much time a contributor might provide to the project. +All contributors implicitly agree to abide by the mKTL code of conduct. + Maintainer ^^^^^^^^^^ @@ -46,6 +48,8 @@ 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. +All maintainers implicitly agree to abide by the mKTL code of conduct. + Communication ------------- From 9bec100190eceb2fbaecfec9bd6bd47c789552bc Mon Sep 17 00:00:00 2001 From: Kyle Lanclos Date: Wed, 18 Mar 2026 11:23:54 -1000 Subject: [PATCH 12/19] Move around the project support and approval sections. --- doc/governance.rst | 70 +++++++++++++++++++++++----------------------- 1 file changed, 35 insertions(+), 35 deletions(-) diff --git a/doc/governance.rst b/doc/governance.rst index dd7cd1d8..236b4c2a 100644 --- a/doc/governance.rst +++ b/doc/governance.rst @@ -6,6 +6,41 @@ organization contributing to mKTL, regardless of their role, implicitly agrees to this policy. +Project support +--------------- + +The principal customer for mKTL and mKTL-based systems is +`W. M. Keck Observatory `_ (WMKO). As such, +WMKO is committed to the ongoing development and maintenance of mKTL, and +will support the participation of at least one maintainer for the duration +of mKTL's operational use, and will internally support contributors as needed +for ongoing development and operational fixes. + +Other participating institutions should make a similar commitment commensurate +with their needs. + + +Approval +-------- + +Changes to mKTL governance require a full consensus among all maintainers, +and ideally a consensus from participating contributors. Significant changes +may also require the approval from supporting institutions. + +Approval of any other changes requires: + + #. A minimum of one maintainer + #. A minimum of two contributors from WMKO + #. A minimum of one contributor from outside WMKO + +There can be overlap between these roles, for example, if a maintainer is +from an external institution. Contributors are not expected to approve their +own contributions, except in the case where no other approvals are available, +for example if there is only one maintainer and their contribution requires +approval. Maintainers have the authority to bypass the normal approval process +but this authority should be used sparingly, if at all. + + Roles ----- @@ -135,20 +170,6 @@ version number, concatenated with a '.' character: * patch, for backwards-compatible bug fixes -Project support ---------------- - -The principal customer for mKTL and mKTL-based systems is -`W. M. Keck Observatory `_ (WMKO). As such, -WMKO is committed to the ongoing development and maintenance of mKTL, and -will support the participation of at least one maintainer for the duration -of mKTL's operational use, and will internally support contributors as needed -for ongoing development and operational fixes. - -Other participating institutions should make a similar commitment commensurate -with their needs. - - User support ------------ @@ -159,24 +180,3 @@ be made to address any deficiencies in the online documentation. The existence of project support does not imply there is a warranty or other resources that the user base is entitled to draw upon should problems arise. - - -Approval --------- - -Changes to mKTL governance require a full consensus among all maintainers, -and ideally a consensus from participating contributors. Significant changes -may also require the approval from supporting institutions. - -Approval of any other changes requires: - - #. A minimum of one maintainer - #. A minimum of two contributors from WMKO - #. A minimum of one contributor from outside WMKO - -There can be overlap between these roles, for example, if a maintainer is -from an external institution. Contributors are not expected to approve their -own contributions, except in the case where no other approvals are available, -for example if there is only one maintainer and their contribution requires -approval. Maintainers have the authority to bypass the normal approval process -but this authority should be used sparingly, if at all. From 2424fa2d4b58b48d4a8ee3308b9983b0037e5e94 Mon Sep 17 00:00:00 2001 From: Kyle Lanclos Date: Wed, 18 Mar 2026 12:55:47 -1000 Subject: [PATCH 13/19] Minor tweak to communication for readability. --- doc/governance.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/governance.rst b/doc/governance.rst index 236b4c2a..f48af342 100644 --- a/doc/governance.rst +++ b/doc/governance.rst @@ -94,7 +94,7 @@ via GitHub; discussion of pull requests should primarily occur in the discussion thread associated with the pull request. Secondary discussions will occur in the #mktl Slack channel in the WMKO Software Coordination workspace. Side conversations are inevitable, but should be brought back to -a common space where all contributors can participate. +a common space where all contributors can participate in the discussion. Contributed code From 8e57eae4060eed5e2b161b4cba5689c23c516e3a Mon Sep 17 00:00:00 2001 From: Kyle Lanclos Date: Wed, 18 Mar 2026 14:08:01 -1000 Subject: [PATCH 14/19] Highlight major.minor.patch. --- doc/governance.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/governance.rst b/doc/governance.rst index f48af342..479140cf 100644 --- a/doc/governance.rst +++ b/doc/governance.rst @@ -163,7 +163,7 @@ mKTL will follow the Python versioning scheme described in `PEP-440 `_, though perhaps with more clarity in the `Python packaging documentation `_ as `semantic versioning `_, with a three part -version number, concatenated with a '.' character: +version number, concatenated with a '.' character (major.minor.patch): * major, for changes breaking backwards compatibility * minor, for backwards-compatible additions or changes From e3ccdf3eeb254f2e47be59d8ca6e2a83e05ff773 Mon Sep 17 00:00:00 2001 From: Kyle Lanclos Date: Wed, 18 Mar 2026 15:22:32 -1000 Subject: [PATCH 15/19] Explicitly state that maintainers are a subset of contributors, which are a subset of users. --- doc/governance.rst | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/doc/governance.rst b/doc/governance.rst index 479140cf..948d323e 100644 --- a/doc/governance.rst +++ b/doc/governance.rst @@ -55,6 +55,8 @@ strengths or weaknesses of mKTL from their perspective. Contributor ^^^^^^^^^^^ +Contributors are a subset of users. + A contributor is anyone who manipulates the source code repository in any context: submitting issues, commenting on issues, submitting pull requests, or any similar activity is considered a contributor. Beyond @@ -67,6 +69,8 @@ All contributors implicitly agree to abide by the mKTL code of conduct. Maintainer ^^^^^^^^^^ +Maintainers are a subset of contributors. + A maintainer is an individual with commit and merge access on the mKTL repository. There will always be an odd number of designated maintainers to ensure a majority vote is possible, should voting situations arise. From a5ab3647652238d7dc5c4779a2f8f82908bbb3e2 Mon Sep 17 00:00:00 2001 From: Kyle Lanclos Date: Wed, 18 Mar 2026 15:38:12 -1000 Subject: [PATCH 16/19] Rephrase for clarity some of the language concerning pull requests. --- doc/governance.rst | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/doc/governance.rst b/doc/governance.rst index 948d323e..502660ce 100644 --- a/doc/governance.rst +++ b/doc/governance.rst @@ -108,12 +108,11 @@ Pull requests ^^^^^^^^^^^^^ All code contributions will occur via pull request. Pull requests shall -be targeted and concise, ideally addressing a single topic (whether or -not it is separately filed as an issue), and being manageable to review. -The general rule of thumb is pull requests should take less than an hour -to review, as an upper bound; similarly, the number of lines changed -should be kept low, with 50-200 lines being a reasonable target, and 500 -lines as an upper bound. These are not firm requirements, but staying +be targeted and concise, ideally addressing a single topic (whether or not +it is separately filed as an issue), and being manageable to review. Pull +requests should take less than an hour to review; similarly, the number of +lines changed should be kept low, with 50-200 lines being a reasonable target, +and 500 lines as an upper bound. These are not firm requirements, but staying within these guidelines helps reduce the burden on maintainers and other reviewers, and increases the likelihood that a pull request can be properly assessed and quickly merged. This assessment process is expected to occur From ffefbff05d39a8c7d203d63788253164a41710e4 Mon Sep 17 00:00:00 2001 From: Kyle Lanclos Date: Thu, 19 Mar 2026 11:26:52 -1000 Subject: [PATCH 17/19] Change the approvals to require two maintainers from WMKO, and one maintainer from outside WMKO. --- doc/governance.rst | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/doc/governance.rst b/doc/governance.rst index 502660ce..36fdaa6a 100644 --- a/doc/governance.rst +++ b/doc/governance.rst @@ -29,16 +29,15 @@ may also require the approval from supporting institutions. Approval of any other changes requires: - #. A minimum of one maintainer - #. A minimum of two contributors from WMKO - #. A minimum of one contributor from outside WMKO + #. A minimum of two maintainers from WMKO + #. A minimum of one maintainer from outside WMKO There can be overlap between these roles, for example, if a maintainer is from an external institution. Contributors are not expected to approve their own contributions, except in the case where no other approvals are available, for example if there is only one maintainer and their contribution requires -approval. Maintainers have the authority to bypass the normal approval process -but this authority should be used sparingly, if at all. +approval. Organization administrators have the authority to bypass the normal +approval process but this authority should be used sparingly, if at all. Roles From 5ba8f2e59641d324d700e456141d1f2dab5fe7a6 Mon Sep 17 00:00:00 2001 From: Kyle Lanclos Date: Mon, 23 Mar 2026 15:21:00 -1000 Subject: [PATCH 18/19] Add a note about contributor status not including approval authority. --- doc/governance.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/doc/governance.rst b/doc/governance.rst index 36fdaa6a..c5c05651 100644 --- a/doc/governance.rst +++ b/doc/governance.rst @@ -63,6 +63,9 @@ basic professional decency there are no expectations or commitments associated with being a contributor, nor are there any limits on how much time a contributor might provide to the project. +Contributor status does not confer approval authority, which rests solely +with maintainers. + All contributors implicitly agree to abide by the mKTL code of conduct. Maintainer From 82c50c8f14ddc88c666eec46648ff5343e3a673c Mon Sep 17 00:00:00 2001 From: Kyle Lanclos Date: Thu, 2 Apr 2026 18:52:30 -1000 Subject: [PATCH 19/19] Jeff suggested stronger wording for the unit tests passing. --- doc/governance.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/governance.rst b/doc/governance.rst index c5c05651..b999cf2f 100644 --- a/doc/governance.rst +++ b/doc/governance.rst @@ -124,7 +124,7 @@ Informative commit messages and other inline documentation should be leveraged whenever practical. Clear expressions of intent go a long way towards understanding code, both for reviews and future debugging. -All pull requests are expected to pass the unit test suite with no errors. +All pull requests must pass the unit test suite with no errors. Code style ^^^^^^^^^^