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
Copy file name to clipboardExpand all lines: README.md
+37-7Lines changed: 37 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -44,7 +44,7 @@ A machine-parseable artifact will be available at `build/html/needs.json`. (ToDo
44
44
A record with checksums of the contents is available at `build/html/guidelines-ids.json`. Users of the coding guidelines can reference this file to determine if there have been changes to coding guidelines contents they should be aware of.
45
45
46
46
47
-
## Running builds offline
47
+
###Running builds offline
48
48
49
49
If you're working without internet access or want to avoid reaching out to remote resources, you can pass the `--offline` flag:
50
50
@@ -57,7 +57,7 @@ This prevents the build system from attempting to fetch remote resources, such a
57
57
It is recommended to use `--offline` if you are running `make.py` frequently during development. The builder fetches data from [the Ferrocene Language Specification website](https://spec.ferrocene.dev/paragraph-ids.json), which may rate-limit repeated requests—leading to delays or failed builds. Using `--offline` can significantly improve build speed and avoid unnecessary network issues during iterative work.
58
58
59
59
60
-
## Build breaking due to out-dated spec lock file
60
+
###Build breaking due to out-dated spec lock file
61
61
62
62
It's a fairly common occurrence for the build to break due to an out of date spec lock file, located at:
63
63
@@ -107,15 +107,45 @@ Open a new PR with only the changes necessary to rationalize the guidelines with
107
107
108
108
We will use the Coding Guidelines Work Items [board](https://github.com/orgs/rustfoundation/projects/1) as a means to break the work down into smaller chunks that can be tackled in a reasonable manner.
109
109
110
-
## Contribution of existing guidelines
111
-
112
-
We are very open to receiving contributed coding guidelines in whole or in part and wholly originally contributions based on learnings from past organizational experience using Rust in safety-critical projects.
113
-
114
110
## Contributing to the coding guidelines
115
111
116
112
See [CONTRIBUTING.md](CONTRIBUTING.md).
117
113
118
-
### Have an idea? Want to discuss it?
114
+
### Diagram for contribution workflow
115
+
116
+
```mermaid
117
+
flowchart TD
118
+
Start(["Start"])
119
+
CodingGuidelineIdea["Coding Guideline Idea"]
120
+
DiscussOnZulip[/"(Optional)<br>Discuss on Zulip"/]
CodingGuidelineIssue -- 6: subcomittee member <br> confirms changes; <br> assigns label to <br> regenerate PR --> CodingGuidelinePR
144
+
CodingGuidelinePR -- 7: subcommittee member <br> approves, adds <br> to merge queue; <br> gets merged to main --> Main
145
+
Main -- process complete --> End
146
+
```
147
+
148
+
### 0. Have an idea for a coding guideline? Want to discuss it?
119
149
120
150
While not mandatory, sometimes you'd like to check into the feasiblity of a guideline or discuss it with others to ensure it's not overlapping an existing guideline. Feel free to drop by the Safety-Critical Rust Consortium's Zulip stream: [here](https://rust-lang.zulipchat.com/#narrow/channel/445688-safety-critical-consortium). Please open a new topic per coding guideline you'd like to discuss.
0 commit comments