You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This section lists community articles that have been discussed, revised, and reviewed by maintainers.
15
+
16
+
Compared to the First Publications section, articles here are closer to long-term, citable content: the text, terminology, code, sources, and scope of application have been organized into a stable state. They retain their status as community articles and are not necessarily part of the main tutorial volumes.
17
+
18
+
## Inclusion Criteria
19
+
20
+
Before an article enters this section, it typically must meet the following criteria:
21
+
22
+
- Technical conclusions have been reviewed by maintainers.
23
+
- Terminology, code blocks, references, and image sources have been organized.
24
+
- The article structure is suitable for long-term reading.
25
+
- There are no significant conflicts with existing content in the main tutorial.
26
+
- Author attribution, licensing, and citation boundaries are clear.
27
+
28
+
## Future Status
29
+
30
+
Some articles may remain in the community articles section as supplementary reading material.
31
+
32
+
If an article is particularly well-suited for the main tutorial, maintainers may, with the author's understanding, reorganize it into the appropriate volume, chapter, or topic.
Tutorial_AwesomeModernCPP focuses primarily on content output. Version numbers measure the magnitude of content progress. Site maintenance, PR, and Issue handling serve the main content, rather than dictating the main rhythm.
10
19
11
-
Tutorial_AwesomeModernCPP is driven primarily by content production. Version numbers measure the size of content progress. Site maintenance, PRs, and Issues support the main content path instead of taking it over.
20
+
## Basic Beat
12
21
13
-
## Basic Rhythm
22
+
Maintainers usually perform a lightweight iteration every two to three days. Each round binds only one primary objective:
14
23
15
-
Maintainers usually run a lightweight iteration every 2 to 3 days. Each iteration should have one main goal:
24
+
- Complete a set of related content.
25
+
- Fix a batch of issues affecting readability.
26
+
- Fill in code, links, or translations for a specific chapter.
27
+
- Address actionable PRs or Issues.
16
28
17
-
- Finish a related group of content.
18
-
- Fix a batch of reading problems.
19
-
- Complete code, links, or translations for a chapter.
20
-
- Handle clearly actionable PRs or Issues.
29
+
A single iteration does not aim to cover all directions. Volume-level roadmaps, long-term candidates, and distant topics remain in `todo/`. Do not split temporary, article-level ideas into new governance files.
21
30
22
-
One iteration does not need to cover every direction. Volume roadmaps, long-term candidates, and future themes remain in `todo/`. Temporary article-level ideas should not become new governance files.
31
+
## Single-Round Maintenance Workflow
23
32
24
-
## Per-Iteration Flow
33
+
Each maintenance round proceeds in the following order:
25
34
26
-
Each maintenance iteration follows this order:
35
+
1. Review current P0/P1 goals in TODO and select one primary content objective.
36
+
2. Quickly check Issues and PRs, handling only those that are actionable, affect the current version, or block readers.
37
+
3. Complete content, example code, indices, and necessary English synchronization for this round.
38
+
4. Run quality checks matching the scope of changes.
39
+
5. If changes are user-perceivable, update the changelog or prepare the next version entry.
27
40
28
-
1. Review the current P0/P1 TODO goals and choose one main content target.
29
-
2. Quickly check Issues and PRs, handling only items that are actionable, release-relevant, or reader-blocking.
30
-
3. Complete the content, example code, indexes, and required English/Chinese sync for the iteration.
31
-
4. Run the quality checks that match the change scope.
32
-
5. If the change is reader-visible, update the changelog or prepare the next release entry.
41
+
PRs and Issues should be checked at least once per round. Urgent issues can be queued at any time, such as site build failures, major page 404s, seriously misleading example code, or external contributions requiring quick feedback.
33
42
34
-
PRs and Issues should be checked at least once per iteration. Urgent problems may interrupt the cycle, such as broken site builds, important 404 pages, misleading example code, or external contributions that need quick feedback.
43
+
## Version Rhythm
35
44
36
-
## Version Cadence
45
+
Version numbers describe the magnitude of changes, rather than forcefully driving the writing rhythm.
37
46
38
-
Version numbers describe the size of change; they should not force the writing schedule.
47
+
-**patch**: Bug fixes, links, site fixes, low-risk text revisions.
48
+
-**minor**: Significant progress in a volume or topic where readers can perceive new learning paths or complete capabilities.
49
+
-**major**: Major adjustments to TODO structure, site architecture, or content system.
39
50
40
-
- patch: typo fixes, links, site fixes, and low-risk text corrections.
41
-
- minor: one volume or topic has clearly moved forward, giving readers a new learning path or complete capability.
42
-
- major: TODO structure, site architecture, or the content system changes substantially.
43
-
44
-
Patch releases can ship as needed. Minor releases usually use a 2 to 4 week observation window and ship only when a topic forms a complete increment. Major releases should stay rare to avoid repeatedly changing reader and contributor entry points.
51
+
patch releases can be made on demand. minor releases usually have an observation window of two to four weeks, and are published only when a topic forms a complete increment. major releases should be restrained to avoid frequently changing the entry perception for readers and contributors.
45
52
46
53
## Tags and Releases
47
54
48
-
Tags and GitHub Releases are used separately. Tags mark lightweight maintenance checkpoints so readers can see ongoing progress through the README badge. GitHub Releases are reserved for content versions that readers should explicitly notice.
55
+
Tags and GitHub Releases are used separately. Tags mark lightweight maintenance nodes, allowing readers to perceive continuous project activity via README badges; GitHub Releases are used only for content versions worthy of specific reader attention.
49
56
50
-
-Patch-level fixes may be tagged without creating a GitHub Release.
51
-
-Minor topic increments should usually create a Release with a changelog.
52
-
-Major structural changes must create a Release and explain migration impact.
57
+
-**patch**level fixes may only create a tag, without a GitHub Release.
58
+
-**minor** level topic progress should usually create a Release, accompanied by a changelog.
59
+
-**major** level structural adjustments must create a Release and explain migration impact.
53
60
54
-
This keeps project activity visible without overwhelming readers with Release notifications.
61
+
This preserves project activity signals while avoiding Release spam.
55
62
56
63
## Definition of Done
57
64
58
-
A content iteration should usually satisfy these conditions:
65
+
When a content iteration is complete, the following conditions should be met as much as possible:
59
66
60
-
- The article can be read independently, with terms and C++ standard versions clearly marked.
61
-
-Related volume pages, chapter indexes, or navigation entries are updated.
62
-
- Example code in the article can compile, or platform/toolchain limits are explicitly stated.
63
-
-Key Chinese and English pages stay in sync; community drafts and low-priority long-form notes may be translated later.
64
-
- Internal links pass checks, and the production build succeeds.
67
+
- The main text is readable independently, with terminology and standard versions clearly marked.
68
+
-Relevant volume homepages, chapter indices, or navigation entries are updated.
69
+
- Example code in the article compiles, or platform and toolchain limitations are explicitly stated.
70
+
- Chinese and English key pages are synchronized; translations for community initial publications and low-priority long articles can be deferred.
71
+
- Internal links pass checks, and production builds pass.
65
72
66
-
For local fixes, run only the relevant checks. Before a release, run the full pre-release checks.
73
+
If the round involves only local fixes, run only relevant checks; if preparing for a release, run full pre-release checks.
67
74
68
75
## PR and Issue Handling
69
76
70
-
Issues are for actionable problems, Discussions are for open-ended learning conversations, and PRs are for concrete changes.
77
+
Issues handle actionable problems, Discussions handle open learning discussions, and PRs handle specific modifications.
71
78
72
-
Handle items in this order:
79
+
Processing priority is as follows:
73
80
74
-
1.Problems that block builds, deployment, or major reading paths.
75
-
2. Clear, low-riskfixes already submitted as PRs.
81
+
1.Issues blocking builds, deployment, or main reading paths.
82
+
2. Clear, low-risk, easy-to-merge fixes in existing PRs.
76
83
3. Content suggestions directly related to the current iteration theme.
77
-
4. Learning questions that can become QA entries, appendix material, or future TODO items.
84
+
4. Learning questions that can be consolidated into QA, appendices, or future TODOs.
78
85
79
-
Learning questions should not fill the Issue list directly. High-quality discussions can be summarized into FAQ entries, appendix pages, or links from the main content.
86
+
Learning questions should not be stuffed directly into the Issue list; high-quality discussions can be organized into FAQs, appendices, or main text links.
80
87
81
88
## Changelog Principles
82
89
83
-
The changelog should describe reader-visible changes, not just file counts.
90
+
Changelogs should describe reader-perceivable changes, rather than simply listing file counts.
84
91
85
-
Prefer recording:
92
+
Recommended records:
86
93
87
-
- Which learning path was added or completed.
94
+
- Which learning paths were added or completed.
88
95
- Which examples can now run or be verified.
89
-
- Which site entries, search behavior, navigation, or community flows improved.
90
-
- Which contributors helped fix specific problems.
96
+
- Which site entry points, search, navigation, or community processes were improved.
97
+
- Which contributors helped fix specific issues.
91
98
92
-
File counts, line counts, and commit counts can be supporting data, but they should not replace the explanation of what changed.
99
+
File counts, line counts, and commit counts can serve as auxiliary data but should not replace change descriptions.
93
100
94
101
## Common Checks
95
102
96
-
Choose checks by change scope during daily maintenance:
103
+
For daily iterations, select checks based on the scope of changes:
This section tracks the development, maintenance, and release rhythm of Tutorial_AwesomeModernCPP itself. It is located under the Community section because these processes directly support content collaboration, PR/Issue handling, and the long-term maintenance of the site.
7
15
8
-
This section documents how Tutorial_AwesomeModernCPP itself is developed, maintained, and released. It lives under the community section because these practices support content collaboration, PR/Issue handling, and long-term site maintenance.
16
+
This section does not replace `todo/`, `changelogs/`, or `CONTRIBUTING.md`:
9
17
10
-
It does not replace `todo/`, `changelogs/`, or `CONTRIBUTING.md`:
18
+
-`todo/` records the content roadmap and volume-level planning.
19
+
-`changelogs/` records changes in released versions.
20
+
-`CONTRIBUTING.md` records contribution, review, and quality guidelines.
21
+
-`community/dev/` records how maintainers drive website and content iteration.
11
22
12
-
-`todo/` tracks content roadmaps and volume-level plans.
13
-
-`changelogs/` records changes that have already shipped.
14
-
-`CONTRIBUTING.md` defines contribution, review, and quality rules.
15
-
-`community/dev/` explains how maintainers move the site and content forward.
23
+
## Roadmap & Versions
16
24
17
-
## Roadmap & Releases
25
+
Want to know what the project is working on next and what has been released? Here are two authoritative sources (hosted in the root of the GitHub repository):
18
26
19
-
Wondering what's next or what has already shipped? These are the two authoritative sources (hosted at the repository root on GitHub):
27
+
- 📋 **[Project Master Roadmap](https://github.com/Awesome-Embedded-Learning-Studio/Tutorial_AwesomeModernCPP/blob/main/todo/000-project-roadmap.md)** — Overall priorities (P0–P3), asset/gap assessment by volume, and near-term focus; for volume-level details, see `todo/010–020` in the same directory.
28
+
- 📦 **[Version Changelogs](https://github.com/Awesome-Embedded-Learning-Studio/Tutorial_AwesomeModernCPP/tree/main/changelogs)** — New content and significant changes for each released version.
20
29
21
-
- 📋 **[Project Roadmap](https://github.com/Awesome-Embedded-Learning-Studio/Tutorial_AwesomeModernCPP/blob/main/todo/000-project-roadmap.md)** — overall priorities (P0–P3), per-volume asset/gap assessment, and near-term focus; volume-level detail lives in `todo/010–020` alongside it.
22
-
- 📦 **[Release History](https://github.com/Awesome-Embedded-Learning-Studio/Tutorial_AwesomeModernCPP/tree/main/changelogs)** — what each released version added or changed.
The development section is for durable maintenance practices, not temporary task lists. Short-term work remains in the relevant volume TODO, and released changes remain in the changelog.
38
+
The Project Development section prioritizes long-term maintenance methods over temporary task lists. Short-term tasks should still go into the corresponding volume-level TODO, and version changes should still go into the changelog.
This section showcases community submissions that have passed basic review and are ready for public reading and discussion.
15
+
16
+
Articles in this first issue will be included in the online documentation site and may be cited in the TAMCPP weekly newsletter. They do not represent the final draft of the main tutorial, and may be updated based on reader feedback, external platform discussions, and maintainer review.
17
+
18
+
## Status Guidelines
19
+
20
+
Articles in this section typically meet the following criteria:
21
+
22
+
- They render correctly.
23
+
- They have no obvious technical errors.
24
+
- Sources, references, images, and code are clearly credited.
25
+
- The author agrees to public display and allows maintainers to make necessary edits.
26
+
27
+
## How to Contribute
28
+
29
+
If you would like to submit an article, you can submit a PR and place the Markdown file in this directory. We recommend using lowercase English and hyphens for filenames, for example:
You can start by submitting just the main content; you do not need to complete the full frontmatter, navigation, and index from the beginning. Maintainers will help organize these details.
36
+
37
+
We suggest specifying the following at the beginning of the article:
0 commit comments