kaboom-standards-organization/rfcs
5
0
Fork 2
Code Issues 1 Pull requests 1 Releases Packages Activity Actions

RFC 0000: Explain what soft/hard requirements are #3

Open
OptimisticDev wants to merge 1 commit from OptimisticDev/rfcs:requirements-explanation into main
pull from: OptimisticDev/rfcs:requirements-explanation
merge into: kaboom-standards-organization:main
Conversation 2 Commits 1 Files changed 1 +2 -2
OptimisticDev commented 2024-10-17 20:08:34 -04:00
Owner
Copy link

Pull request to resolve issues behind #2

Pull request to resolve issues behind #2
OptimisticDev added 1 commit 2024-10-17 20:08:34 -04:00
OptimisticDev force-pushed requirements-explanation from e510f5fba8 to 38806c0201 2024-10-17 20:09:37 -04:00 Compare
OptimisticDev requested review from Owners 2024-10-17 20:12:28 -04:00
OptimisticDev removed review request for Owners 2024-10-17 20:12:49 -04:00
OptimisticDev requested review from chipmunkmc 2024-10-17 20:13:10 -04:00
OptimisticDev requested review from amy 2024-10-17 20:13:11 -04:00
OptimisticDev requested review from khy 2024-10-17 20:13:11 -04:00
OptimisticDev requested review from hhhzzzsss 2024-10-17 20:13:11 -04:00
amy requested changes 2024-10-17 20:59:01 -04:00
Dismissed
amy left a comment
Owner
Copy link

I think we should just do what Dinhero said and just use RFC 2119 for this. Here's what it defines for "must" and "should":

  1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
    definition is an absolute requirement of the specification.

  2. SHOULD This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

This is pretty much exactly what we're specifying, it's just more verbose.

Here's how the RFC tells people to use it:

In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.

I think we should just do what Dinhero said and just use RFC 2119 for this. Here's what it defines for "must" and "should": > 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the > definition is an absolute requirement of the specification. > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. This is pretty much exactly what we're specifying, it's just more verbose. Here's how the RFC tells people to use it: > In many standards track documents several words are used to signify > the requirements in the specification. These words are often > capitalized. This document defines these words as they should be > interpreted in IETF documents. Authors who follow these guidelines > should incorporate this phrase near the beginning of their document: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > RFC 2119.
OptimisticDev commented 2024-10-18 03:08:02 -04:00
Author
Owner
Copy link

I think we should just do what Dinhero said and just use RFC 2119 for this. Here's what it defines for "must" and "should":

  1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
    definition is an absolute requirement of the specification.

  2. SHOULD This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

This is pretty much exactly what we're specifying, it's just more verbose.

Here's how the RFC tells people to use it:

In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.

To avoid confusion, I will henceforth be referring to RFC 2119 as "the RFC", and the genesis RFC contained in this repository as "the KRFC".

Unfortunately, I feel the language is too complicated for this project. At the very minimum, if these definitions are included in the KRFC, they will have to be cut down. This is why I have written my own version similar enough to what the RFC states, but simple enough to keep within the bounds of the KRFC.

> I think we should just do what Dinhero said and just use RFC 2119 for this. Here's what it defines for "must" and "should": > > 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the > > definition is an absolute requirement of the specification. > > > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > > may exist valid reasons in particular circumstances to ignore a > > particular item, but the full implications must be understood and > > carefully weighed before choosing a different course. > > This is pretty much exactly what we're specifying, it's just more verbose. > > Here's how the RFC tells people to use it: > > > In many standards track documents several words are used to signify > > the requirements in the specification. These words are often > > capitalized. This document defines these words as they should be > > interpreted in IETF documents. Authors who follow these guidelines > > should incorporate this phrase near the beginning of their document: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > > "OPTIONAL" in this document are to be interpreted as described in > > RFC 2119. To avoid confusion, I will henceforth be referring to RFC 2119 as "the RFC", and the genesis RFC contained in this repository as "the KRFC". Unfortunately, I feel the language is too complicated for this project. At the very minimum, if these definitions are included in the KRFC, they will have to be cut down. This is why I have written my own version similar enough to what the RFC states, but simple enough to keep within the bounds of the KRFC.
amy commented 2024-10-19 09:56:04 -04:00
Owner
Copy link

That's fair.

That's fair.
amy approved these changes 2024-10-19 09:56:10 -04:00
This pull request can be merged automatically.
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u requirements-explanation:OptimisticDev-requirements-explanation
git checkout OptimisticDev-requirements-explanation

Merge

Merge the changes and update on Forgejo.
git checkout main
git merge --no-ff OptimisticDev-requirements-explanation
git checkout main
git merge --ff-only OptimisticDev-requirements-explanation
git checkout OptimisticDev-requirements-explanation
git rebase main
git checkout main
git merge --no-ff OptimisticDev-requirements-explanation
git checkout main
git merge --squash OptimisticDev-requirements-explanation
git checkout main
git merge --ff-only OptimisticDev-requirements-explanation
git checkout main
git merge OptimisticDev-requirements-explanation
git push origin main
Sign in to join this conversation.
Reviewers
No reviewers
chipmunkmc
khy
hhhzzzsss
amy
Labels
Clear labels
  
Compat
Breaking
Breaking change that won't be backward compatible

  
Kind/Bug

Something is not working

  
Kind/Documentation

Documentation changes

  
Kind/Enhancement

Improve existing functionality

  
Kind/Feature

New functionality

  
Kind/Security

This is security issue

  
Kind/Testing

Issue or pull request related to testing

  
Priority
Critical
The priority is critical

  
Priority
High
The priority is high

  
Priority
Low
The priority is low

  
Priority
Medium
The priority is medium

  
Reviewed
Confirmed
Issue has been confirmed

  
Reviewed
Duplicate
This issue or pull request already exists

  
Reviewed
Invalid
Invalid issue

  
Reviewed
Won't Fix
This issue won't be fixed

  
Status
Abandoned
Somebody has started to work on this but abandoned work

  
Status
Blocked
Something is blocking this issue or pull request

  
Status
Need More Info
Feedback is required to reproduce issue or to continue work

No labels
Compat
Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: kaboom-standards-organization/rfcs#3
No description provided.
Delete branch "OptimisticDev/rfcs:requirements-explanation"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?