|
1 | | -# Contributing to FlyPython |
| 1 | +# Contributing to the FlyPython catalog |
2 | 2 |
|
3 | | -FlyPython is a bilingual, reviewed catalog of durable Python and AI-agent |
4 | | -resources. Contributions should improve accuracy, source quality, or the |
5 | | -catalog workflow. General Python questions belong in |
6 | | -[GitHub Discussions](https://github.com/flypythoncom/python/discussions). |
| 3 | +FlyPython maintains a bilingual, reviewed source catalog used by |
| 4 | +[flypython.com](https://flypython.com/). Contributions should improve source |
| 5 | +quality, factual accuracy, or the maintenance workflow. General Python questions |
| 6 | +belong in [GitHub Discussions](https://github.com/flypythoncom/python/discussions). |
7 | 7 |
|
8 | | -Before contributing, read the [curation policy](docs/CURATION_POLICY.md). |
| 8 | +Read the [curation policy](docs/CURATION_POLICY.md) before contributing. |
9 | 9 |
|
10 | 10 | ## Permissions |
11 | 11 |
|
12 | | -This repository currently does not grant a general license to reuse its |
13 | | -content or code. Public visibility is not permission to copy, redistribute, |
14 | | -or relicense repository material. Contributors must submit only material |
15 | | -they have the right to submit and must preserve any required third-party |
16 | | -notices. A contribution does not change the terms of third-party material. |
| 12 | +This repository currently does not grant a general license to reuse its content |
| 13 | +or code. Public visibility is not permission to copy, redistribute, or relicense |
| 14 | +repository material. Contributors must submit only material they have the right |
| 15 | +to submit and retain required third-party notices. |
17 | 16 |
|
18 | 17 | ## Propose a change |
19 | 18 |
|
20 | 19 | Use the matching issue form before a larger change: |
21 | 20 |
|
22 | | -- **Resource proposal** for a new catalog entry. |
| 21 | +- **Resource proposal** for a new official source. |
23 | 22 | - **Broken link** for an unreachable or replaced resource. |
24 | | -- **Security report** for a vulnerability. Follow [SECURITY.md](SECURITY.md) |
| 23 | +- **Security report** for a vulnerability; follow [SECURITY.md](SECURITY.md) |
25 | 24 | instead of opening a public issue. |
26 | 25 |
|
27 | | -Small typo, metadata, or maintenance fixes may go directly to a pull request. |
28 | | -Keep each pull request focused on one purpose. |
| 26 | +Small typo, metadata, or tooling fixes may go directly to a focused pull request. |
29 | 27 |
|
30 | | -## Catalog changes |
| 28 | +## Catalog sources |
31 | 29 |
|
32 | | -`_data/resources.yml` is the canonical catalog source. Do not add or change a |
33 | | -resource only in a rendered Markdown page. |
| 30 | +The canonical source is the `catalog/` directory: |
34 | 31 |
|
35 | | -Each resource entry must include these fields: |
| 32 | +- `catalog/catalog.yml` contains catalog-level review state. |
| 33 | +- `catalog/paths.yml` defines the four bilingual learning paths. |
| 34 | +- `catalog/resources/<id>.yml` contains one reviewed resource. |
| 35 | +- `catalog.json` is generated output and must not be edited by hand. |
36 | 36 |
|
37 | | -- `id`, `path`, `title`, and `url` |
| 37 | +Every resource file must include: |
| 38 | + |
| 39 | +- `id`, `path`, `order`, `title`, and `url` |
38 | 40 | - `source_type`, `level`, and `language` |
39 | 41 | - `why_en` and `why_zh` |
40 | 42 | - `reviewed_on` and `status` |
41 | 43 | - `requires_key`, `risk`, and `featured` |
42 | 44 |
|
| 45 | +The filename must match the stable resource ID. Resource `order` values must be |
| 46 | +unique and consecutive within each path. |
| 47 | + |
43 | 48 | Descriptions and classifications require human review. Do not use an LLM or a |
44 | 49 | web-search API to generate them. Prefer official documentation, official |
45 | 50 | standards, and official project pages. |
46 | 51 |
|
47 | | -A 403, 429, or transient 5xx response is not enough to delete a resource. Mark |
48 | | -it for review and provide repeatable evidence. |
| 52 | +A 403, 429, timeout, or transient 5xx response is not enough to delete a |
| 53 | +resource. Mark it for human review and provide repeatable evidence. |
49 | 54 |
|
50 | 55 | ## Local setup |
51 | 56 |
|
52 | | -Install the exact Python version from `.python-version`, Ruby, Bundler, and the |
53 | | -repository dependencies: |
| 57 | +Install the exact Python version from `.python-version` and the locked |
| 58 | +development dependencies: |
54 | 59 |
|
55 | 60 | ```bash |
56 | 61 | python -m venv .venv |
57 | 62 | . .venv/bin/activate |
58 | 63 | python -m pip install -r requirements-dev.lock.txt |
59 | | -bundle install |
60 | 64 | ``` |
61 | 65 |
|
62 | | -## Required validation |
| 66 | +After changing catalog sources, regenerate the public export: |
| 67 | + |
| 68 | +```bash |
| 69 | +python tools/export_catalog.py |
| 70 | +``` |
63 | 71 |
|
64 | | -Run the same checks as CI before requesting review: |
| 72 | +Run the same deterministic checks as CI: |
65 | 73 |
|
66 | 74 | ```bash |
67 | 75 | python -m pytest |
68 | 76 | python tools/validate_catalog.py |
69 | | -bundle exec jekyll build |
70 | | -bundle exec ruby tests/render_security_test.rb |
| 77 | +python tools/export_catalog.py --check |
71 | 78 | ``` |
72 | 79 |
|
73 | | -Maintainers can run the networked link audit from GitHub Actions with the |
74 | | -scheduled **Catalog link audit** workflow. For a deliberate local audit of |
75 | | -every catalog entry, including same-origin URLs: |
| 80 | +Maintainers can run the networked link audit through GitHub Actions. For a |
| 81 | +deliberate local audit of every catalog entry: |
76 | 82 |
|
77 | 83 | ```bash |
78 | 84 | python tools/check_links.py --mode all --output reports/link-check.json |
79 | 85 | ``` |
80 | 86 |
|
81 | | -Network link fetching is intentionally excluded from pull-request CI. A pull |
82 | | -request can contain untrusted URLs, and status checks must remain deterministic. |
83 | | -Any review-needed link result fails the scheduled audit so a maintainer must |
84 | | -inspect it; it does not by itself justify removing the resource. |
| 87 | +Network fetching is excluded from pull-request CI. Any review-needed result |
| 88 | +fails the scheduled audit for maintainer inspection, but does not by itself |
| 89 | +justify removing a resource. |
85 | 90 |
|
86 | 91 | ## Pull request checklist |
87 | 92 |
|
88 | | -- Keep catalog data and bilingual output consistent. |
89 | | -- Include evidence for maintenance, license, safety, and adoption claims. |
| 93 | +- Keep source data and the generated `catalog.json` consistent. |
| 94 | +- Preserve English and Chinese meaning. |
| 95 | +- Include evidence for maintenance, ownership, access, and safety claims. |
90 | 96 | - Do not call a project production-ready without current evidence. |
91 | | -- Do not commit secrets, API keys, analytics IDs, generated reports, or local |
92 | | - build output. |
93 | | -- Submit only material you have the right to submit and retain any required |
94 | | - third-party notice. |
95 | | -- Explain user-visible changes and list the commands you ran. |
96 | | - |
97 | | -## Review and merge |
98 | | - |
99 | | -Maintainers may request edits, reclassify an entry, or decline resources that |
100 | | -do not meet the curation policy. Passing automated checks does not replace |
101 | | -editorial review. After merge, maintainers verify the GitHub Pages deployment |
102 | | -and the production domain. |
| 97 | +- Do not commit secrets, generated reports, caches, or local environments. |
| 98 | +- Explain consumer-visible changes and list the validation results. |
| 99 | + |
| 100 | +Passing automation does not replace editorial review. After merge, a website |
| 101 | +consumer must deliberately update its pinned catalog commit before the new data |
| 102 | +appears on flypython.com. |
0 commit comments