[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Handling of JIRA issues
I think there are four classes of comments:
1) Spelling/Grammar/Tone/bad citation: Assign to Editor and just fix it
2) Blinding Flash of Obvious Errors. May be a technical change but is totally non-controversial: Assign to Editor and just fix it
3) Difficult issues raised in limited area. Discuss in Commitee. If Editor makes proposal, afterwards, assign to Committee Member most concerned to sign off on change.
4) Big issues that need meeting time.
By default, Jira assigns all issues to me. (Lucky me).
When you start work, assign it to yourself, and open it.
Anyone can weigh in on comments, or make comments about the comments. This is encouraged.
If you think that 4 issues are the same, we can make some them sub-tasks.
1/2 can be addressed by noting in resolution: “Did as suggested” Or even “Rejected item 3, accepted all others.” Move issue to resolved but DO NOT CLOSE
3. Put your proposed resolution in Jira. If you think we need approval, drop the list a note and we will put it on the agenda. We can move to resolved in committee
4. Point them out. Discuss in meeting. Make comments on Jira.
When we are “all done”, we can vote to accept the resolutions en mass, and direct that they be closed.
Of course, sometime the resolution of an issue is to refuse to do what was requested, that’s OK. It still must be noted in the comments.
IF you fix the issue when working on WD25, please so note in the Jira.
"When one door closes, another opens; but we often look so long and so regretfully upon the closed door that we do not see the one which has opened for us."
-- Alexander Graham Bell
This is primarily an email to Toby, but I thought I’d include the list just for the benefit of information.
Is our plan for addressing JIRA issues to hold any TC teleconference time discussing them? Or simply try to discuss online via JIRA comments? I added some comments to many of the recently posted issues, but not to the ones where I agree the change needs to be made as recommended. I am happy to assign all of the 1.1. core spec issues to me. Some of them I will just do, they are clearly problems in the spec. Others I would like to have some further discussion on some of them (via JIRA or teleconf time) before making the recommended changes.