|
Size: 8136
Comment:
|
Size: 8191
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| = (DRAFT for discussion with full PSF Membership) = |
(DRAFT for discussion with full PSF Membership)
These are DRAFT guidelines for a new approach to making significant strategic decisions for the PSF, in cases where neither confidentiality nor an urgent response are required. It builds directly on the more inclusive membership model introduced in the 2014 revisions to the Python Software Foundation By-laws.
Folks familiar with the Python Enhancement Proposal process used by groups such as the CPython core development team and the Python Packaging Authority to resolve significant design decisions should not find any surprises in the philosophy behind these proposed guidelines, although the exact mechanics involved are quite different. Elements of Red Hat's internal "Open Decision Making Framework" and the Fedora change approval process have also influenced the specific design proposed.
Approval process for these guidelines
These draft guidelines are currently posted for discussion with the full PSF membership on the psf-members list. They will be amended as appropriate based on that discussion, and then placed before the Board for formal ratification through the Board resolution process.
The mechanics of that process will be handled in accordance with the guidelines below (bootstrapping!).
Out of scope items
The following items are specifically out of scope for this discussion:
Investing in relevant enhancements to MoinMoin, or changing to a different collaborative editing technology entirely. MoinMoin's existing capabilities are entirely sufficient for this proposal, and discussing switching to something else would be a distraction from the core objective of establishing the PSF's equivalent of PEP 1.
Defining how to republish the details of at least active programs on the main python.org site. That's a separate entirely technical discussion related to the capabilities of the python.org service to consume content defined elsewhere and republish it as part of the site. See this RFE for more details.
Any Deferred feature listed throughout the body of the proposal. These notes are included for discussion purposes to clarify that addressing certain limitations of the current proposal is a task being left until later in order to prioritise getting a usable initial version of the process in place as soon as possible.
(DRAFT for discussion with full PSF Membership)
PSF Strategic Decision Making Process
The primary mechanism for strategic decision making in the PSF is through resolutions of the PSF Board. Members of the PSF Board of Directors are elected annually in accordance with the PSF Bylaws, and bear the ultimate responsibility for determining how the PSF pursues its mission to:
... promote, protect, and advance the Python programming language, and to support and facilitate the growth of a diverse and international community of Python programmers.
However, some proposed clarifications of or changes to the way the PSF pursues its strategic priorities are of sufficient import that they will benefit from a period of open discussion amongst the PSF membership prior to presentation for a Board resolution.
Similarly, new Working Group charters (as described in the Bylaws) will likely benefit from a period of collaborative discussion on the details of the charter prior to their presentation to the Board.
Non-binding polls of PSF Voting Members
At their discretion, the PSF Board may choose to include non-binding polls in ballots issued to PSF members. This may be appropriate in situations where a policy decision with no obviously correct answer needs to be made, and the Board is unable to find a clear reasoned consensus. In these cases, the collective opinion of the broader PSF membership is likely to provide an additional valuable data point that individual Directors may take into account when voting on any associated Board resolutions.
Deferred feature: These non-binding polls will initially be sent out solely through the formal PSF voting infrastructure. While it is likely desirable to also eventually make use of a simpler consensus assessment mechanism akin to Loomio within the context of the main PSF infrastructure in order to improve discoverability for new members, that specific proposal is being omitted from this initial iteration as it is far from clear how best to pursue providing such a service (one possibility would be to integrate it into HyperKitty, the recommended mail archiver/web gateway for the next generation Mailman 3 mailing list service).
Formal Proposals
Proposals for Discussion
Any PSF Member (including Basic Members) may use the Python wiki to submit a proposal for discussion with the full PSF membership. Such proposals should be filed under the PythonSoftwareFoundation/ProposalsForDiscussion section of the wiki. For example:
Deferred feature: There is currently no automatic link between registering as a PSF Member and gaining write access to the Python wiki, and addressing that limitation will require some significant enhancements to the PSF's identity management infrastructure. In the meantime refer to https://wiki.python.org/psf/ to request write access if you wish to submit a proposal.
Proposals for Resolution
Any PSF Director or Officer may determine that a particular proposal is ready for resolution and move it to the PythonSoftwareFoundation/ProposalsForResolution section of the wiki. For example:
Proposals submitted for resolution will be resolved either directly by a Board resolution, or, at the Board's discretion, by a full binding vote of eligible PSF Voting Members.
Active Policies
Any proposal which is resolved favourably and is not amending an existing program will be moved by a PSF Director or Officer to the PythonSoftwareFoundation/ActivePolicies section of the wiki. For example:
Proposals to amend an existing policy will instead be used to appropriately update the relevant policy page, and the proposal itself moved to the ArchivedProposals section of the wiki.
Retired Policies
If a previously active PSF Policy is retired, then it will be moved by a PSF Director or Officer to the PythonSoftwareFoundation/RetiredPolicies section of the wiki.
Archived Proposals
If a proposal is resolved unfavourably, or is otherwise withdrawn from consideration, it will be moved by a PSF Director or Officer to the PythonSoftwareFoundation/ArchivedProposals section of the wiki.
Access Control
All sections of the Python wiki referenced in this proposal will remain readable by the general public. Write access to the following sections may be restricted as follows:
PythonSoftwareFoundation/ProposalsForDiscussion: all PSF Members (including Basic Members)
PythonSoftwareFoundation/ProposalsForResolution: PSF Directors and Officers
PythonSoftwareFoundation/ActivePolicies: PSF Directors and Officers
PythonSoftwareFoundation/RetiredPolicies: PSF Directors and Officers
PythonSoftwareFoundation/ArchivedProposals: PSF Directors and Officers
Technical Notes
When "moving" proposals between categories, a redirect from past locations to the new location should be put in place using the MoinMoin #redirect directive.
At least initially, the access restrictions described above may not be programmatically enforced, to allow for easier delegation of proposal and policy management.