A self-paced, hands-on training for people who want to contribute to Eclipse S-CORE: build, review, fix and rebase in a realistic S-CORE module, without any risk to a real project.
S-CORE work products are typed, linked and checked by the build, and every change reaches a repository through a reviewed pull request. Someone who has only read the process description meets the consequences for the first time in a real pull request. This training lets you meet them first in a module where nothing can break.
For whom: people who will review or write work products in S-CORE in a quality, safety or
security role. Further tracks are planned; training/README.md says how one is added.
After the training you can:
| Stage | You can | Tasks | Material | Solution |
|---|---|---|---|---|
| 0 Environment | set up the S-CORE toolchain and sign the Eclipse Contributor Agreement | 0.1 | — | — |
| 1 Git | follow an upstream, write a commit that carries its reasoning, raise an issue with the S-CORE form | 1.1, 1.2-1.3 | the module itself | in the task |
| 2 Build | build clean, tell what the build checks from what only pre-commit checks, find the cause of a red build, recognise a stale incremental build | 2.1, 2.2-2.4 | patches/build-* |
Stage 2 |
| 3 Process | trace a work product to its workflow and template, find what the project decided about it, record an open point with owner and trigger | 3.1, 3.2 | process description, eclipse-score/score |
open research, none |
| 4 Review | review a pull request for form and for content, and answer a review with evidence | 4.1, 4.2, 4.3 | patches/r1–r3, reviews/r3.json |
Stage 4 |
| 5 Module | bring a document to the current template state through a rebase conflict, and fill it in | 5.1-5.3, 5.4 | patches/r4, your track's document |
PR #R4, Stage 5 |
| 6 Wrap-up | review another track's work, perform a formal document review with a checklist, reflect | 6.1, 6.2-6.3 | patches/r5-* |
PR #R5 |
What it does not teach: the S-CORE architecture, writing code, or how to become a committer.
- Your own copy. You make a copy of this repository in your own GitHub account and run the setup there. It fills the copy with defect branches, prepared pull requests and about fifteen task issues.
- A fictive module.
Training_Moduleis made from the S-CORE module template and follows the S-CORE process description. Some of its documents are wrong on purpose. - Tracks: quality, safety, security. About five working days.
- Self-organised. There is no tutor and no support. When something breaks, you repair it
yourself;
TRAINING.mdsays how. - Open solutions.
training/SOLUTIONS.mdlists every defect. Reading it first only shortens what you learn. - Certificate. When every task is done, a workflow in your copy issues a certificate of completion.
Start here: TRAINING.md. Maintaining or extending the training:
training/README.md. Feedback and bug reports: the issue forms of this
repository.