6898daf0ce
* Initial setup. This does a few things: - Adds some placeholders following the Diátaxis framework (https://diataxis.fr) - Sets up Sphinx with MyST parser for Markdown in addition to rST. - Uses the well-known PyData Sphinx theme. - Moves some already existing Markdown files into the docs directory. - Sets up the initial doc review GitHub action to auto-deploy to GitHub pages. * Activate conda env. * Remove custom action. * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * Make the dir. * Push directly * Add readthedocs config. * Disable GitHub pages deployment for now. * Add release and latest workflows as well. * Make clear that this is work in progress. * Made docs merge ready, added What is PyScript section with example. * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * Replace `on:tags:` with `on:create:` The existing trigger is apparently not in the GHA spec * Pretty format YAML * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * add s3 sync and permissions * Leave status message in PR. * Redirect from docs.pyscript.net/ to docs.pyscript.net/latest/ * Delete latest directory before deployment. * Update review and release workflows, too. * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * Allow access to S3 for review and release doc workflow. * Fix name of workflow. * Bump up Python version. * Because YAML. * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * Revert move to 3.10. * Fix sitemap. * Remove status settgin from release and latest build. * Comment out cleanup. * Add write permissions for statuses. * More permissions? * Fix artifact name. * Use appropriate concurrency. * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * .zip not needed * Align name of workflows with CI workflows. * Add checks permission. * Set a notice instead. * Move to sphinx-design. * Add sphinx-autobuild. * Use frontmatter more. * Add section for mdformat but disable it for now. See https://github.com/executablebooks/mdformat-myst/pull/9 for more details. * Fix fencing. * Actually using html renderer. * Revert moving governance files. * Use full URLs for governance docs. * Added warning. * Fix copyright and author. * Another minor fix. * Use GitHub Action summary instead of notice. * Fix variable name. Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> Co-authored-by: Matt Kramer <mkramer@anaconda.com> Co-authored-by: ximena9201 <ximenandrea.ro@gmail.com>
3.6 KiB
Governance Policy
This document provides the governance policy for the Project. Maintainers agree to this policy and to abide by all Project policies, including the code of conduct, trademark policy, and antitrust policy by adding their name to the maintainers.md file.
1. Roles.
This project may include the following roles. Additional roles may be adopted and documented by the Project.
1.1. Maintainers. Maintainers are responsible for organizing activities around developing, maintaining, and updating the Project. Maintainers are also responsible for determining consensus. This Project may add or remove Maintainers with the approval of the current Maintainers.
1.2. Contributors. Contributors are those that have made contributions to the Project.
2. Decisions.
2.1. Consensus-Based Decision Making. Projects make decisions through consensus of the Maintainers. While explicit agreement of all Maintainers is preferred, it is not required for consensus. Rather, the Maintainers will determine consensus based on their good faith consideration of a number of factors, including the dominant view of the Contributors and nature of support and objections. The Maintainers will document evidence of consensus in accordance with these requirements.
2.2. Appeal Process. Decisions may be appealed by opening an issue and that appeal will be considered by the Maintainers in good faith, who will respond in writing within a reasonable time. If the Maintainers deny the appeal, the appeal my be brought before the Organization Steering Committee, who will also respond in writing in a reasonable time.
3. How We Work.
3.1. Openness. Participation is open to anyone who is directly and materially affected by the activity in question. There shall be no undue financial barriers to participation.
3.2. Balance. The development process should balance the interests of Contributors and other stakeholders. Contributors from diverse interest categories shall be sought with the objective of achieving balance.
3.3. Coordination and Harmonization. Good faith efforts shall be made to resolve potential conflicts or incompatibility between releases in this Project.
3.4. Consideration of Views and Objections. Prompt consideration shall be given to the written views and objections of all Contributors.
3.5. Written procedures. This governance document and other materials documenting this project's development process shall be available to any interested person.
4. No Confidentiality.
Information disclosed in connection with any Project activity, including but not limited to meetings, contributions, and submissions, is not confidential, regardless of any markings or statements to the contrary.
5. Trademarks.
Any names, trademarks, logos, or goodwill developed by and associated with the Project (the "Marks") are controlled by the Organization. Maintainers may only use these Marks in accordance with the Organization's trademark policy. If a Maintainer resigns or is removed, any rights the Maintainer may have in the Marks revert to the Organization.
6. Amendments.
Amendments to this governance policy may be made by affirmative vote of 2/3 of all Maintainers, with approval by the Organization's Steering Committee.
Part of MVG-0.1-beta. Made with love by GitHub. Licensed under the CC-BY 4.0 License.