1. Creating an issue
1. Issues can be created at any point in the revision cycle. The revision process may have dates after which issues are not guaranteed to be examined for a particular revision of the LRM.
2. For everyone with write access to the SV DB, they should file issues directly in the database
3. If the filer does not have access to the SV DB, the filer can send mail to the appropriate SV-* committee, and the Chair will take the responsibility of entering the issue in the database. If an issue is to be filed this way, the Subject line of the issue must read Errata: <issue title>.
4. Newly filed issues will have status:new
2. Accepting an issue
1. Once an issue has been added to an SV-* committee’s list of new issues, it is examined by the committee. The following actions are possible:
1. The issue description is determined to be incomplete
1. The Chair will assign someone to communicate with the filer of the issue to get a better description
2. The issue will move to status:feedback
2. The issue is determined by vote of the committee to require no change to the LRM
1. Some issues may not require changes to the LRM, questions, etc
Note: Questions should be answered in the bugnotes section and communicated to the filer.
2. The issue will be moved to status:resolved with resolution:not a bug
3. The issue is determined to belong to another committee
1. In the database, the owner for the issue will be updated to the correct category with status:new.
2. The Chair of the current committee will inform the Chair of the new committee that this action has happened
4. The issue is accepted by the committee
1.
The issue is moved to status:confirmed
2. The type field is updated to reflect whether the issue is an Errata, Clarification, or Enhancement
3. The issue is prioritized
1. Priority:immediate for issue that must be addressed before the next revision of the LRM
2. All other priorities can be used by each team as they deem necessary to prioritize issues that are not required for the next revision of the LRM
3. Assigning an issue
1. When the committee is ready to work on an issue, it is marked as status:assigned, and the assigned-to field is updated to reflect the assignee
4. Proposal for an issue
1. Every proposal must completely describe every change required by the LRM. Descriptions like: find every reference to byte and change it to char is not acceptable
2. To describe a proposal, indicate the section of the LRM that the change needs to be made in.
1. Indicate the old wording with the label “REPLACE”, and copy the relevant text, including some context. This can be done in Acrobat Reader, for example, by using the Text Select Tool.
2. Indicate the new wording with the label “WITH,” and again copy the relevant text, including some context. Then add text using blue and delete text using red strikethrough.
3. Finally, save in a widely readable format, such as HTML.
4. Templates reflecting this method can be found at http://www.eda-twiki.org/sv
3. Proposals should be added to an issue using the upload file button. The appropriate SV-* committee should then be sent an email indicating that a proposal exists.
4. Approval of an issue by an SV-* Committee
1. Once a proposal exists, the assigned SV-* Committee discuss the issue, and vote for its acceptance.
1. If a proposal is not passed, new proposals are developed as above and the approval process restarts
2. Once a vote resolving an issue has passed
1. The issue is moved to status:resolved , resolution:fixed
2. Several pieces of data need to be recorded for each issue in the additional information field to allow groups of similar errata to be approved by the P1800 in batches:
1. The date the issue is resolved
2. Whether or not the vote was unanimous
3. Categories of the change
1. BNF
2. Simple text change: typo, etc
3. LRM change or clarification
4. Usage errata enhancements
5. Review by the Champions
1. Prior to the presentation to the P1800, the Champions should review all of the SV-* approved changes. The additional information field should be updated with
1. Champions unanimously approve
2. Champions unanimously recommend a specific alternative
3. Champions cannot reach concensus
6. Approval of issue by the P1800
1. All issues in the status:resolved must be approved by the P1800 whether they are resolution:fixed or resolution:not a bug.
2. The P1800 will consider an issue using their voting process.
1. For issues that are not approved
1. The issue goes to status:assigned and the appropriate SV-* committee is informed. A reason for the reopening of the issue must be included in the additional information field.
2. For issues that are approved
1. If the issue has resolution:not a bug it goes to status:closed
2. If the issue has resolution:fixed
1. The issue is assigned to category:SV-LRM, status:new
2. The date of the approval vote is recorded in the additional information field
7. Addition to the LRM
1. If the LRM Committee does not have sufficient information to incorporate a change into the LRM, it will send the issue back to the appropriate SV-* Committee by
1.
Assign the issue to category:SV-*
with status:assigned, priority:immediate
2. Mail is sent to the Chair of the SV-* indicating that the issue is reopened
2. If the LRM Committee successfully incorporates the change, it will:
1. Publish a draft of the LRM including the changes
2. Update the issue to status:acknowledged
3. Record Fixed draft version in the additional information field
8. LRM Review by the SV-* Committees
1. Once an issue has status:acknowledged, the appropriate SV-* committee must review the changes for correctness
1. If the change is correct, the issue is moved to status:closed
2. If the change is not correct and the description was correct, the issue is moved to category:SV-LRM and status:new, and mail is sent to the LRM team
3. If the change is not correct and the description of the change needs to be modified, the issue is changed to status:assigned
Is an SV-* committee done?
An SV-* Committee is done with their work for a particular revision of the LRM when the following conditions are true:
1. No issue entered before the submission deadline for a revision of the LRM has priority:none
2.
No issue has priority:immediate
3.
No issue has status:acknowledged
There are issues for the P1800 to consider when the following condition is true:
1. There are issues with status:resolved
The LRM reflects all resolved issues when the following conditions are true:
1. No issue has category:SV-LRM
2. No issue has status:acknowledged
The LRM ready to be sent to ballot when the following conditions are true:
1. No issue entered before the submission deadline for a revision of the LRM has priority:none
2.
No issue has priority:immediate
3.
No issue has status:acknowledged
4. No issue has status:resolved
1. No issue has category:SV-LRM
Database Access
1. Read only access
Anyone can read the status of the database. They need to log on with user id: guest and password: guest
2. Member company access
All companies that are members of the P1800 have an account that will allow them to file issues in the database. The Chair of the P1800 approves the addition of new companies to this class of database access
3. Developer access
Chairs of the SV-* committees can nominate to the Technical Chair members of their committees who will be making proposals to have Developer access. This access style allows the developer the ability to update the issues in the database.
4. Manager access
The Chairs of the SV-* committees have permission to update issues.
Enhancements requested
1. A status to record that a proposal has been made.
2. Category SV-LRM needs to be added.