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: CODEOWNERS.md
+4-4Lines changed: 4 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -1,8 +1,8 @@
1
1
# Code Owners
2
-
<!-- TODO: Who are the points of contact in your project who are responsible/accountable for the project? This can often be an engineering or design manager or leader, who may or may not be the primary maintainers of the project. List them by GitHub Username-->
3
2
4
-
- natalialuzuriaga
3
+
<!-- TODO: Who are the points of contact in your project who are responsible/accountable for the project? This can often be an engineering or design manager or leader, who may or may not be the primary maintainers of the project. List them by GitHub Username-->
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+29-50Lines changed: 29 additions & 50 deletions
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,3 @@
1
-
<!--- # NOTE: Modify sections marked with `TODO` -->
2
-
3
1
# How to Contribute
4
2
5
3
<!-- Basic instructions about where to send patches, check out source code, and get development support.-->
@@ -15,39 +13,47 @@ We encourage you to read this project's CONTRIBUTING policy (you are here), its
15
13
16
14
## Getting Started
17
15
18
-
<!--- TODO: If you have 'good-first-issue' or 'easy' labels for newcomers, mention them here.-->
16
+
To run the project locally,
17
+
18
+
1. Start up a HTTP server using python: `python3 -m http.server 8000`
19
+
2. Upon launch, here is the form! Right click to inspect to open developer tools for troubleshooting
20
+
3. Fill out form
21
+
4. Click submit, which triggers a local download of the completed code.json
19
22
20
23
### Team Specific Guidelines
21
24
22
-
<!-- TODO: This section helps contributors understand any team structure in the project (formal or informal.) Encouraged to point towards the MAINTAINERS.md file for further details.-->
25
+
- Please try to keep pull requests to a reasonable size; try to split large contributions to multiple PRs
26
+
- Please create pull requests into dev unless the contribution is some kind of bugfix or urgent hotfix
27
+
- Document and explain the contribution clearly according to provided standards when possible
28
+
- Feel free to reach out to us if there is any confusion. A list of the project maintainers is found here: [MAINTAINERS.md](./MAINTAINERS.md)
23
29
24
30
### Building dependencies
25
31
26
-
<!--- TODO: This step is often skipped, so don't forget to include the steps needed to install on your platform. If you project can be multi-platform, this is an excellent place for first time contributors to send patches!-->
32
+
Python is required in order to run this project locally.
27
33
28
34
### Building the Project
29
35
30
-
<!--- TODO: Be sure to include build scripts and instructions, not just the source code itself! -->
36
+
1. Start up a HTTP server using python: `python3 -m http.server 8000`
31
37
32
38
### Workflow and Branching
33
39
34
-
<!--- TODO: Workflow Example
35
40
We follow the [GitHub Flow Workflow](https://guides.github.com/introduction/flow/)
36
41
37
42
1. Fork the project
38
-
2. Check out the `main` branch
43
+
2. Check out the `dev` branch
39
44
3. Create a feature branch
40
45
4. Write code and tests for your change
41
-
5. From your branch, make a pull request against `DSACMS/codejson-generator/main`
46
+
5. From your branch, make a pull request against `DSACMS/codejson-generator/dev`
42
47
6. Work with repo maintainers to get your change reviewed
43
48
7. Wait for your change to be pulled into `DSACMS/codejson-generator/main`
44
49
8. Delete your feature branch
45
-
-->
46
50
47
51
### Testing Conventions
48
52
49
53
<!--- TODO: Discuss where tests can be found, how they are run, and what kind of tests/coverage strategy and goals the project has. -->
50
54
55
+
We are working on tests at the moment. Stay tuned.
56
+
51
57
### Coding Style and Linters
52
58
53
59
<!--- TODO: HIGHLY ENCOURAGED. Specific tools will vary between different languages/frameworks (e.g. Black for python, eslint for JavaScript, etc...)
@@ -59,9 +65,9 @@ We follow the [GitHub Flow Workflow](https://guides.github.com/introduction/flow
59
65
60
66
-->
61
67
62
-
### Writing Issues
68
+
Prettier is used for HTML/CSS and Javascript formatting. Stay tuned for the prettier config file.
63
69
64
-
<!--- TODO: Example Issue Guides
70
+
### Writing Issues
65
71
66
72
When creating an issue please try to adhere to the following format:
67
73
@@ -80,12 +86,9 @@ When creating an issue please try to adhere to the following format:
80
86
List all relevant steps to reproduce the observed behavior.
81
87
82
88
see our .github/ISSUE_TEMPLATE.md for more examples.
83
-
-->
84
89
85
90
### Writing Pull Requests
86
91
87
-
<!-- TODO: Make a brief statement about where to file pull/merge requests, and conventions for doing so. Link to PULL_REQUEST_TEMPLATE.md file.
88
-
89
92
Comments should be formatted to a width no greater than 80 columns.
90
93
91
94
Files should be exempt of trailing spaces.
@@ -113,56 +116,32 @@ columns (You can use `fmt -n -p -w 80` to accomplish this).
113
116
114
117
Some important notes regarding the summary line:
115
118
116
-
* Describe what was done; not the result
117
-
* Use the active voice
118
-
* Use the present tense
119
-
* Capitalize properly
120
-
* Do not end in a period — this is a title/subject
121
-
* Prefix the subject with its scope
119
+
- Describe what was done; not the result
120
+
- Use the active voice
121
+
- Use the present tense
122
+
- Capitalize properly
123
+
- Do not end in a period — this is a title/subject
124
+
- Prefix the subject with its scope
122
125
123
-
see our .github/PULL_REQUEST_TEMPLATE.md for more examples.
124
-
-->
126
+
see our .github/PULL_REQUEST_TEMPLATE.md for more examples.
125
127
126
128
## Reviewing Pull Requests
127
129
128
-
<!--- TODO: Make a brief statement about how pull-requests are reviewed, and who is doing the reviewing. Linking to MAINTAINERS.md can help.
129
-
130
-
Code Review Example
131
-
132
-
The repository on GitHub is kept in sync with an internal repository at
133
-
github.cms.gov. For the most part this process should be transparent to the
134
-
project users, but it does have some implications for how pull requests are
135
-
merged into the codebase.
136
-
137
130
When you submit a pull request on GitHub, it will be reviewed by the project
138
-
community (both inside and outside of github.cms.gov), and once the changes are
139
-
approved, your commits will be brought into github.cms.gov's internal system for
140
-
additional testing. Once the changes are merged internally, they will be pushed
141
-
back to GitHub with the next sync.
142
-
143
-
This process means that the pull request will not be merged in the usual way.
144
-
Instead a member of the project team will post a message in the pull request
145
-
thread when your changes have made their way back to GitHub, and the pull
146
-
request will be closed.
147
-
148
-
The changes in the pull request will be collapsed into a single commit, but the
149
-
authorship metadata will be preserved.
150
-
151
-
-->
131
+
community, and once the changes are approved, your commits will be brought into the main branch that deploys the production website.
152
132
153
133
<!--
154
134
## Shipping Releases
155
135
156
-
<!-- TODO: What cadence does your project ship new releases? (e.g. one-time, ad-hoc, periodically, upon merge of new patches) Who does so?
136
+
<!-- TODO: What cadence does your project ship new releases? (e.g. one-time, ad-hoc, periodically, upon merge of new patches) Who does so?
157
137
-->
158
138
159
139
## Documentation
160
140
161
-
<!-- TODO: Documentation Example
141
+
At the moment, we are working on documentation for the CMS code.json schema. Stay tuned.
162
142
163
143
We also welcome improvements to the project documentation or to the existing
164
144
docs. Please file an [issue](https://github.com/DSACMS/codejson-generator/issues).
165
-
-->
166
145
167
146
## Policies
168
147
@@ -174,7 +153,7 @@ questions, just [shoot us an email](mailto:[email protected]).
174
153
175
154
### Security and Responsible Disclosure Policy
176
155
177
-
*Submit a vulnerability:* Vulnerability reports can be submitted through [Bugcrowd](https://bugcrowd.com/cms-vdp). Reports may be submitted anonymously. If you share contact information, we will acknowledge receipt of your report within 3 business days.
156
+
_Submit a vulnerability:_ Vulnerability reports can be submitted through [Bugcrowd](https://bugcrowd.com/cms-vdp). Reports may be submitted anonymously. If you share contact information, we will acknowledge receipt of your report within 3 business days.
178
157
179
158
For more information about our Security, Vulnerability, and Responsible Disclosure Policies, see [SECURITY.md](SECURITY.md).
0 commit comments