Update CONTRIBUTING and CHANGELOG

Change log: - Add release dates for 3.0 (2024-04-15) and 2.3 (2022-11-03) Contributing guideline: - Add info about sign off - Update branch names - Minor change to `development/v3.0.1` branch - Major change to `development/v3.1` branch (this may be not accurate, need comments) Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
bact · Jun 13, 2024 · 047384b · 047384b
1 parent aac3e38
commit 047384b
Show file tree

Hide file tree

Showing 2 changed files with 60 additions and 21 deletions.
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -1,11 +1,12 @@
 # Change Log
+
 All notable changes to this project will be documented in this file.
 
-## 3.0
+## 3.0 (2024-04-15)
 
 See the [v3.0 GitHub release notes](https://github.com/spdx/spdx-spec/releases/tag/v3.0) for changes.
 
-## 2.3
+## 2.3 (2022-11-03)
 
 See the [v2.3 GitHub release notes](https://github.com/spdx/spdx-spec/releases/tag/v2.3) for changes.
 

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -1,41 +1,79 @@
 # Contributing
 
-The SPDX specification is maintained by the SPDX [legal][spdx-legal] and [tech][spdx-tech] teams.
-Design and planning is primarily done via the team [mailing][spdx-legal-list] [lists][spdx-tech-list] and meetings.
+The SPDX specification is maintained by the SPDX [legal][spdx-legal] and
+[tech][spdx-tech] teams.
+Design and planning is primarily done via the team [mailing][spdx-legal-list]
+[lists][spdx-tech-list] and meetings.
 
 ## Contribution License Agreement
 
-Contributions to this repo are made pursuant to the [SPDX Community Specification Contributor License Agreement 1.0][cla]. You do not need to submit a signed copy of the contributor license agreement; by making a contribution to this repo, you agree to the terms set forth in that agreement.
+Contributions to this repo are made pursuant to the
+[SPDX Community Specification Contributor License Agreement 1.0][cla]. You do
+not need to submit a signed copy of the contributor license agreement; by
+making a contribution to this repo, you agree to the terms set forth in that
+agreement.
 
 ## Submitting changes
 
-Always write a clear log message for your commits. One-line messages are fine for small changes, but significant changes should look like this:
+Always write a clear log message for your commits. One-line messages are fine
+for small changes, but significant changes should look like this:
 
-    $ git commit -m "Subject of the commit
-    > 
-    > A paragraph describing what changed and its impact."
+```shell
+$ git commit -m "Subject of the commit
+>
+> A paragraph describing what changed and its impact.
+>
+> Signed-off-by: Contributor Name <name@example.com>"
+```
 
-A properly formed Git commit subject line should always be able to complete the following sentence: if applied, this commit will "Subject of the commit". For example :
+Every commit message also needs a sign-off line, or it will not pass a test in
+the workflow. This line starts with `Signed-off-by:` and specifies the name and
+the email address of the person who submitted the changes. You can also use the
+`-s` or `--signoff` option with `git commit` to automatically append the line
+to your commit message (it will use `user.name` and `user.email` from your
+`.git/config` configuration file).
 
-    if applied, this commit will Add chapter on Security Vunerabilities in SPDX
-    if applied, this commit will Delete section with deprecated SPDX attributes 
-    if applied, this commit will Fix grammar in Package Version field description
+A properly formed Git commit subject line should always be able to complete the
+following sentence: if applied, this commit will "Subject of the commit".
 
-Git itself uses this approach. When you merge something it will generate a commit message like "Merge branch...", or when reverting "Revert...".
+For example :
+
+```text
+if applied, this commit will Add chapter on Security Vunerabilities in SPDX
+if applied, this commit will Delete section with deprecated SPDX attributes 
+if applied, this commit will Fix grammar in Package Version field description
+```
+
+Git itself uses this approach. When you merge something it will generate a
+commit message like "Merge branch...", or when reverting "Revert...".
 
 ### Minor Changes
-Minor changes such as markup and typo fixes may be submitted directly to this repository (either as [issues][] or [pull-requests][]) without previous discussion.
-Please submit all minor changes against the `development/v2.3` branch which is the current version of the SPDX specification.
+
+Minor changes such as markup and typo fixes may be submitted directly to this
+repository (either as [issues][] or [pull-requests][]) without previous
+discussion.
+
+Please submit all minor changes against the `development/v3.0.1` branch which
+is the current development version of the SPDX specification.
 
 ### Major Changes
-Any change that break backwards compatibility or requires significant tooling changes is considered a major change.
-You may want to discuss major changes on the mailing list first to get design feedback before investing time in a pull request.
-Please submit all major changes against the `development/v3.0` which is the next major version of the specification. 
+
+Any change that break backwards compatibility or requires significant tooling
+changes is considered a major change.
+You may want to discuss major changes on the mailing list first to get design
+feedback before investing time in a pull request.
+
+Please submit all major changes against the `development/v3.1` which is the
+next major version of the specification.
 
 ### Target Milestones
-When submitting an issue or pull request, please add a suggested release milestone.  This will ensure the issue or pull request is reviewed for inclusion in that release.
 
-If your issue or pull request is independent of a release, you can use the `release-independent` milestone.
+When submitting an issue or pull request, please add a suggested release
+milestone. This will ensure the issue or pull request is reviewed for inclusion
+in that release.
+
+If your issue or pull request is independent of a release, you can use the
+`release-independent` milestone.
 
 [cla]: https://github.com/spdx/governance/blob/main/0._SPDX_Contributor_License_Agreement.md
 [issues]: https://github.com/spdx/spdx-spec/issues/