Skip to content

Commit e920cd6

Browse files
andorskandorsk
authored
Initial commit
0 parents  commit e920cd6

9 files changed

+5925
-0
lines changed

‎.gitignore

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
node_modules

‎CODEOWNER

Lines changed: 65 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,65 @@
1+
# This is a comment.
2+
# Each line is a file pattern followed by one or more owners.
3+
4+
# These owners will be the default owners for everything in
5+
# the repo. Unless a later match takes precedence,
6+
# @global-owner1 and @global-owner2 will be requested for
7+
# review when someone opens a pull request.
8+
* @global-owner1 @global-owner2
9+
10+
# Order is important; the last matching pattern takes the most
11+
# precedence. When someone opens a pull request that only
12+
# modifies JS files, only @js-owner and not the global
13+
# owner(s) will be requested for a review.
14+
*.js @js-owner #This is an inline comment.
15+
16+
# You can also use email addresses if you prefer. They'll be
17+
# used to look up users just like we do for commit author
18+
# emails.
19+
*.go [email protected]
20+
21+
# Teams can be specified as code owners as well. Teams should
22+
# be identified in the format @org/team-name. Teams must have
23+
# explicit write access to the repository. In this example,
24+
# the octocats team in the octo-org organization owns all .txt files.
25+
*.txt @octo-org/octocats
26+
27+
# In this example, @doctocat owns any files in the build/logs
28+
# directory at the root of the repository and any of its
29+
# subdirectories.
30+
/build/logs/ @doctocat
31+
32+
# The `docs/*` pattern will match files like
33+
# `docs/getting-started.md` but not further nested files like
34+
# `docs/build-app/troubleshooting.md`.
35+
docs/* [email protected]
36+
37+
# In this example, @octocat owns any file in an apps directory
38+
# anywhere in your repository.
39+
apps/ @octocat
40+
41+
# In this example, @doctocat owns any file in the `/docs`
42+
# directory in the root of your repository and any of its
43+
# subdirectories.
44+
/docs/ @doctocat
45+
46+
# In this example, any change inside the `/scripts` directory
47+
# will require approval from @doctocat or @octocat.
48+
/scripts/ @doctocat @octocat
49+
50+
# In this example, @octocat owns any file in a `/logs` directory such as
51+
# `/build/logs`, `/scripts/logs`, and `/deeply/nested/logs`. Any changes
52+
# in a `/logs` directory will require approval from @octocat.
53+
**/logs @octocat
54+
55+
# In this example, @octocat owns any file in the `/apps`
56+
# directory in the root of your repository except for the `/apps/github`
57+
# subdirectory, as its owners are left empty.
58+
/apps/ @octocat
59+
/apps/github
60+
61+
# In this example, @octocat owns any file in the `/apps`
62+
# directory in the root of your repository except for the `/apps/github`
63+
# subdirectory, as this subdirectory has its own owner @doctocat
64+
/apps/ @octocat
65+
/apps/github @doctocat

‎CONTRIBUTING.md

Lines changed: 218 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,218 @@
1+
# Contribution Guide
2+
3+
Please refer to the [DIF contributing guide](https://raw.githubusercontent.com/decentralized-identity/template-for-work-items/refs/heads/main/CONTRIBUTING.md) for broader DIF policies around contributions and code of conduct that impact work done with DIF Labs.
4+
5+
[DIF Labs Charter](https://github.com/decentralized-identity/labs/blob/main/docs/charter.md) and [Operating Processes](https://github.com/decentralized-identity/labs/blob/main/docs/process.md) describe what it means to be a project in DIF Labs.
6+
7+
The following document extends the initial contributing guide with DIF Labs specific information. All DIF wide code of conduct and contributing agreements apply.
8+
9+
As a contributor to a DIF Labs project, you may:
10+
11+
* Join the discussion and share ideas in our [Discord channel](https://discord.gg/48DgSG4skR)
12+
* Explore projects in [Github](https://github.com/decentralized-identity/labs)
13+
* Raise an issue or feature request in our issue tracker
14+
* Help another contributor with one of their questions, or a documentation
15+
review
16+
* Suggest improvements by supplying a pull request or opening a discussion
17+
* Evangelize our work together in conferences, podcasts, and social media
18+
spaces.
19+
20+
Projects are managed by the project leads. Please see the proposal for more information on who is leading the project. Project leads have discretion on how to manage their projects, as long as they comply with DIF Agreements.
21+
22+
**Please Keep Your Repo Scoped To Your Proposal!**
23+
24+
We are sure that you have other work around your proposal you may be working on, but remember that only the proposal is what was accepted into DIF Labs. Please make sure your work is scoped to it.
25+
26+
## Contributing With Github
27+
28+
This section is designed to help you make an edit if you aren't familiar with
29+
using Github and want to make a change to the repository. These are non-normative.
30+
31+
### Basic Change Flow
32+
33+
If you're not familiar with Github and Git, here's a few simple steps you can
34+
use to get going and to contribute to the repository *without ever touching the
35+
command line*.
36+
37+
1. [Fork the repo into your
38+
account](https://docs.github.com/en/get-started/quickstart/fork-a-repo)
39+
40+
<div align="center"><img width=400 src=https://user-images.githubusercontent.com/8604639/196454640-13428816-918b-43d1-af7b-24c54959f756.png></div>
41+
42+
<div align="center"><img width=400 src=https://user-images.githubusercontent.com/8604639/196456303-be5ccc86-9f7b-4159-9387-2d4260333516.png></div>
43+
44+
2. Find the file you want to edit. [Click the pen tool on the top right of the
45+
file to edit it]([https://www.youtube.com/watch?v=uE2DxUfZjtE](https://docs.github.com/en/repositories/working-with-files/managing-files/editing-files)). If you want to add a file, click "Add File". Click "create new branch". [Learn More](https://docs.github.com/en/repositories/working-with-files/managing-files/editing-files)
46+
47+
<div align="center"><img width=400 src=https://user-images.githubusercontent.com/8604639/196453797-8cf73fee-e032-44d0-a32b-fcdf7dccf3fc.png></div>
48+
<div align="center"><img width=400 src=https://user-images.githubusercontent.com/8604639/196456484-ac4160a4-657d-4ef3-bca5-21ad0fa9d8e8.png></div>
49+
50+
3. Make your changes. When you are ready, click [Pull
51+
Request](https://youtu.be/rgbCcBNZcdQ?t=205) on the bar above the file. Then
52+
create `New Pull Request` and choose to set the request to merge to the
53+
`TechArch:main` branch. Put any information you want to describe your changes
54+
on the description, and you're done! [Learn More](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork).
55+
56+
<div align="center"><img width=400 src=https://user-images.githubusercontent.com/8604639/196454843-23080862-1f8a-4514-a3e0-59bfb9350adf.png></div>
57+
<div align="center"><img width=400 src=https://user-images.githubusercontent.com/8604639/196454824-a20039f9-ab87-4806-b321-891eea222438.png></div>
58+
59+
#### Updating your PR on Changes Requested
60+
61+
If you've gotten some comments about needing to fix a PR, the process is really
62+
simple. You do NOT need to create a new PR.
63+
64+
1. Go to the file in **your branch** that you want to edit.
65+
2. Click the edit button ( step 2 from when you created the initial edit )
66+
3. Make edits, but this time, instead of creating a **new** branch, commit to
67+
the same branch. Your changes will propogate to the PR.
68+
69+
<div align="center"><img width=400 src=https://user-images.githubusercontent.com/8604639/199773674-443fbf9d-1a2b-4968-87d8-45b9adff21ab.png></div>
70+
71+
4. You may want to re-request review. Click the sync button to do so:
72+
73+
### Advanced Change Flow
74+
75+
As a more advanced user, there are few ways you can manage your Github
76+
repository:
77+
78+
1. [You can use the github web
79+
editor](https://docs.github.com/en/codespaces/the-githubdev-web-based-editor)
80+
2. [You can use github desktop](https://desktop.github.com/)
81+
3. [You can use the
82+
cli](https://git-scm.com/book/en/v2/Getting-Started-The-Command-Line)
83+
4. Something else! Git is extremely powerful if you want to spend the time
84+
researching.
85+
86+
### Commits
87+
88+
- [You must sign your
89+
commits](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits)
90+
- Please try to keep your commit history clean. We do not enforce this but it is
91+
encouraged.
92+
93+
### Branching:
94+
95+
- Nobody will work directly on the `main` branch. All changes must occur over a
96+
PR and off the main branch.
97+
- We encourage, but do not enforce branching naming using the following schema:
98+
`<type>/<description>` ex. `edit/fix-fig4-label`.
99+
- The main-branch should always have the latest approved changes
100+
- Custom "feature" branches may be used for special purposes, e.g. for groups to
101+
work on a larger section of text
102+
- Branching will occur on forks, not over the main repository. This is to ensure
103+
that the main repository is not cluttered with lots of branches from contributors.
104+
105+
### Tagging
106+
107+
- Version tags are used for each release of the document
108+
- Releases should be versioned and if needed, appended with a pre-release tag,
109+
e.g. "v1", "v3-RC1", "v4-IIW39"
110+
- Versioning should be simple, only major releases numbered, prepended with
111+
letter v. e.g. v1, v2, v3.
112+
- Branch protection rules will exist to not allow a person to directly commit to
113+
`main`.
114+
115+
### Pull Requests
116+
117+
The below documents some basic best practices for your pull requests.
118+
119+
- Please make sure to ask an editor to review your Pull Request.
120+
- Write descriptive and consistent names.
121+
- Create a clear PR title and description.
122+
- Keep PRs short as possible
123+
- Try to keep a transparent audit trail of your conversation so people can
124+
follow it.
125+
- Avoid rewrites by getting feedback early.
126+
- Request additional reviewers to create dialogue.
127+
- Be precise in your comments about what needs to be fixed.
128+
129+
### Review
130+
131+
- Review of PR's is done by appointed editors. See the
132+
[GOVERNANCE](GOVERNANCE.md) file for more information.
133+
- Issues labeled with `status: needs-review` should contain a PR code OR the
134+
change text directly in the issue (for those not Git-savvy)
135+
- When you create an issue or a PR, please try to tag them appropriately,
136+
including adding a `status: needs-review` label to the issue/PR.
137+
- Every week, the editors will go through the issues and tag them appropriately.
138+
- If the PR is ready to be merged, it is tagged with `accepted` -label
139+
- In normal circumstances, any editor may merge changes tagged with label
140+
`accepted`
141+
- The editor can try to merge the PR to the main branch.
142+
- If PR is not rebased and commit histories are not in sync, the PR can be
143+
merged if there are no overlapping changes with the history. In this case it
144+
is the merging editor's responsibility to ensure that the merging is clean and
145+
no unwanted changes happen.
146+
- In case of change conflicts, the editor requests the PR creator to rebase
147+
against current main branch and resubmit the PR.
148+
- After review, an `editor` may change the status to `status: last-call`. This
149+
would signal a 5 day delay for close.
150+
- If nobody disagrees with the `status: last-call`, the issue is accepted and
151+
merged back into `main`.
152+
- Sometimes the editor group may agree to a controlled merging process and
153+
decide that merging happens only by a selected editor (e.g. release owner) or
154+
during editor meetings. This may happen when a release of the document is
155+
coming soon and only some specific changes are allowed.
156+
157+
## Issues
158+
159+
- Anyone may raise an issue
160+
- Every week editors will go through the new issues, and label them.
161+
- Please provide as much clarity as possible around an issue topic. Ideally, you
162+
are always answering the following:
163+
* what is the issue?
164+
* why is it important?
165+
* what would trigger closure of the ticket?
166+
- Issues that are not commented on for over 90 days, and reviewed to not be
167+
relevant will be closed by an editor
168+
- Please do not hesitate to self assign yourself if you would like to address an
169+
issue.
170+
171+
## Labels
172+
173+
### Priority Labels
174+
175+
Priority labels are used to describe the impact and focus of the issue. Higher
176+
priority means it is more likely to find focus within the group.
177+
178+
| Priority | Label | Usage |
179+
|----------|----------|--------------------------------------------------------------------------------------------|
180+
| priority | critical | Progress on this issue is critical to the group's forward progress. |
181+
| priority | high | It is important for the group to resolve this issue soon. |
182+
| priority | medium | This issue is important to resolve before the next release. |
183+
| priority | low | This issue is "nice to have" for the next release, but could be deferred if time runs out. |
184+
185+
### Type Labels
186+
187+
Type labels are labels the define the nature of the issue and/or the correction
188+
itself.
189+
190+
| Type | Label | Usage |
191+
|------|------------|----------------------------------------------------------------------------|
192+
| type | editorial | The issue only involves wording and not normative content. |
193+
| type | content | The issue involves normative content; resolution requires group consensus. |
194+
| type | correction | The issue is fixing a recognized problem in the current version. |
195+
| type | formatting | The issue involves fixing formatting. |
196+
| type | figure | The issue involves a figure that it missing or needs to be revised. |
197+
| type | admin | The issue is administrative and NOT about the deliverable. |
198+
199+
### Status Labels
200+
201+
Status labels are labels that are used to help identify the current state of the
202+
issue, so that we may accurately classify the work to do on it.
203+
204+
| Status | Label | Usage |
205+
|--------|-------------------|-------------------------------------------------------------------------------------------------------------------|
206+
| status | unassigned | The issue is new and has not yet been assigned to anyone. |
207+
| status | in-progress | The issue has been assigned and work is in progress. |
208+
| status | needs-review | A resolution (or concrete step forward) has been proposed and needs review. |
209+
| status | blocked | Progress is currently blocked; the block should be explained in a comment. |
210+
| status | on-hold | Progress is currently on hold; the reason should be explained in a comment. |
211+
| status | deferred | Consensus has been reached that this issue can be deferred to a subsequent version. |
212+
| status | abandoned | Consensus has been reached that this issue can be abandoned. |
213+
| status | PR-needed | Consensus has been reached and this issue is now waiting for a PR to be submitted. |
214+
| status | PR-in-progress | The issue is linked to a PR that is in progress |
215+
| status | PR-completed | The issue is linked to a PR that is complete and waiting for review. |
216+
| status | PR-accepted | The issue is linked to a PR that has been accepted and is waiting for merge. |
217+
| status | PR-merged | The issue is linked to a PR that has been merged; this issue can now be closed. |
218+
| status | status: last-call | The issue has been resolved by some other mechanism documented in the comments and is now in **5 day last call.** |

0 commit comments

Comments
 (0)