tahoe-lafs/tahoe-lafs
tahoe-lafs
/
tahoe-lafs
2
0
Fork 0
Code Issues Pull Requests 23 Packages Projects Releases 1 Wiki Activity

3659 Add ticket triage role to dev guide #1032

Merged
May-Lee merged 9 commits from dev-guide-ticket-triage into master 2021-04-13 14:35:30 +00:00
Conversation 1 Commits 9 Files Changed 4 +29
May-Lee commented 2021-04-03 18:28:58 +00:00 (Migrated from github.com)
Copy Link

Fixes ticket:3659

Fixes ticket:3659
coveralls commented 2021-04-03 18:44:53 +00:00 (Migrated from github.com)
Copy Link

Coverage Status

Coverage decreased (-0.009%) to 95.028% when pulling e386a1e705 on dev-guide-ticket-triage into 964a637156 on master.

[![Coverage Status](https://coveralls.io/builds/38769979/badge)](https://coveralls.io/builds/38769979) Coverage decreased (-0.009%) to 95.028% when pulling **e386a1e705c50b5c84d009a366613e2bfa4ad0d0 on dev-guide-ticket-triage** into **964a637156e3a318af0108a29f858bf113cdef37 on master**.
sajith (Migrated from github.com) requested changes 2021-04-04 12:37:32 +00:00
sajith (Migrated from github.com) left a comment
Copy Link

There are two warnings when building docs, as reported by the CI:

/root/project/docs/ticket-triage.rst:26: WARNING: Bullet list ends without a blank line; unexpected unindent.
looking for now-outdated files... none found
pickling environment... done
checking consistency... /root/project/docs/ticket-triage.rst: WARNING: document isn't included in any toctree
done

Can we fix them?

There are two warnings when building docs, [as reported by the CI](https://app.circleci.com/pipelines/github/tahoe-lafs/tahoe-lafs/2203/workflows/5868c682-cfca-4741-a2bb-56c4d7dfbc42/jobs/49355): ``` /root/project/docs/ticket-triage.rst:26: WARNING: Bullet list ends without a blank line; unexpected unindent. looking for now-outdated files... none found pickling environment... done checking consistency... /root/project/docs/ticket-triage.rst: WARNING: document isn't included in any toctree done ``` Can we fix them?
docs/ticket-triage.rst
sajith (Migrated from github.com) commented 2021-04-04 12:36:35 +00:00
Copy Link

I don't think Trac has a provision to delete tickets. A ticket's status can be changed to invalid, duplicate, won't fix, somebody else's problem, etc.

I don't think Trac has a provision to delete tickets. A ticket's status can be changed to invalid, duplicate, won't fix, somebody else's problem, etc.
May-Lee (Migrated from github.com) reviewed 2021-04-04 22:49:05 +00:00
docs/ticket-triage.rst
May-Lee (Migrated from github.com) commented 2021-04-04 22:49:05 +00:00
Copy Link

Cool, thanks for spotting that! I didn't even think to look for warnings :) A bad habit - caring only about errors and forgetting about warnings ;) I have fixed it.

About deletion: I made and deleted a dummy ticket just now. But, I think perhaps the greater discussion is whether we want to delete tickets. I think it's perfectly okay, but if people want to do something that is more history-preserving like change its status, that's okay w/me too.

I favor deletion because

  1. Some tickets are no longer relevant because perhaps there's a speculative feature that would not be feasible or useful to add, or they they don't have anything actionable or other vital content in them.
  2. if something is really important, then a person will make a ticket again. I would guess that there are already duplicated or duplicate-like tickets in Trac.
  3. My sense is that we'd be relatively conservative in choosing to delete tickets.

Screenshot from 2021-04-05 00-32-50

Cool, thanks for spotting that! I didn't even think to look for warnings :) A bad habit - caring only about errors and forgetting about warnings ;) I have fixed it. About deletion: I made and deleted a dummy ticket just now. But, I think perhaps the greater discussion is whether we want to delete tickets. I think it's perfectly okay, but if people want to do something that is more history-preserving like change its status, that's okay w/me too. I favor deletion because 1) Some tickets are no longer relevant because perhaps there's a speculative feature that would not be feasible or useful to add, or they they don't have anything actionable or other vital content in them. 2) if something is really important, then a person will make a ticket again. I would guess that there are already duplicated or duplicate-like tickets in Trac. 3) My sense is that we'd be relatively conservative in choosing to delete tickets. ![Screenshot from 2021-04-05 00-32-50](https://user-images.githubusercontent.com/12126401/113523230-d2485e80-95a6-11eb-9d76-059ece8ed9a5.png)
sajith (Migrated from github.com) reviewed 2021-04-05 01:56:14 +00:00
docs/ticket-triage.rst
sajith (Migrated from github.com) commented 2021-04-05 01:56:14 +00:00
Copy Link

Cool, thanks for spotting that! I didn't even think to look for warnings :) A bad habit - caring only about errors and forgetting about warnings ;) I have fixed it.

It is really my fault. I should have thought about this when adding that CI step. :-)

About deletion: I made and deleted a dummy ticket just now. But, I think perhaps the greater discussion is whether we want to delete tickets. I think it's perfectly okay, but if people want to do something that is more history-preserving like change its status, that's okay w/me too.

I favor deletion because

1. Some tickets are no longer relevant because perhaps there's a speculative feature that would not be feasible or useful to add, or they they don't have anything actionable or other vital content in them.

2. if something is really important, then a person will make a ticket again. I would guess that there are already duplicated or duplicate-like tickets in Trac.

3. My sense is that we'd be relatively conservative in choosing to delete tickets.

Ah I didn't know it was possible to delete Trac tickets. Thanks!

There's also a question of etiquette when removing other people's words though. If someone has spent some of their time and effort on writing a ticket, in general it is better to be respectful of that.

If I have made some silly mistake when filing a ticket, I can probably delete it afterwards without causing much harm, before anyone else has added their thoughts to it. Once someone else has chimed in with a comment or some sort of useful feedback, I will have to be careful about deleting that ticket.

Likewise I wouldn't want to delete a ticket someone else has created, unless it contains some kind of abuse or spam. We do not have that problem right now though. :-)

In case 1, a better resolution would be communicating why something can't be done. There likely won't be a case 2, if we delete tickets. They're likely to silently go away, or go badmouth us elsewhere.

> Cool, thanks for spotting that! I didn't even think to look for warnings :) A bad habit - caring only about errors and forgetting about warnings ;) I have fixed it. It is really my fault. I should have thought about this when adding that CI step. :-) > About deletion: I made and deleted a dummy ticket just now. But, I think perhaps the greater discussion is whether we want to delete tickets. I think it's perfectly okay, but if people want to do something that is more history-preserving like change its status, that's okay w/me too. > > I favor deletion because > > 1. Some tickets are no longer relevant because perhaps there's a speculative feature that would not be feasible or useful to add, or they they don't have anything actionable or other vital content in them. > > 2. if something is really important, then a person will make a ticket again. I would guess that there are already duplicated or duplicate-like tickets in Trac. > > 3. My sense is that we'd be relatively conservative in choosing to delete tickets. Ah I didn't know it was possible to delete Trac tickets. Thanks! There's also a question of etiquette when removing other people's words though. If someone has spent some of their time and effort on writing a ticket, in general it is better to be respectful of that. If I have made some silly mistake when filing a ticket, I can probably delete it afterwards without causing much harm, before anyone else has added their thoughts to it. Once someone else has chimed in with a comment or some sort of useful feedback, I will have to be careful about deleting that ticket. Likewise I wouldn't want to delete a ticket someone else has created, unless it contains some kind of abuse or spam. We do not have that problem right now though. :-) In case 1, a better resolution would be communicating why something can't be done. There likely won't be a case 2, if we delete tickets. They're likely to silently go away, or go badmouth us elsewhere.
May-Lee (Migrated from github.com) reviewed 2021-04-05 11:25:22 +00:00
docs/ticket-triage.rst
May-Lee (Migrated from github.com) commented 2021-04-05 11:25:22 +00:00
Copy Link

It is really my fault. I should have thought about this when adding that CI step. :-)

No worries :) Like I said, I generally ignore warnings unless I know what to do with them. I am used to rspec/rake in ruby, which looks like this:

image

Likewise I wouldn't want to delete a ticket someone else has created, unless it contains some kind of abuse or spam. We do not have that problem right now though. :-)

Okay, I'll reword the line to avoid deletion as a form of resolution.

> > It is really my fault. I should have thought about this when adding that CI step. :-) > No worries :) Like I said, I generally ignore warnings unless I know what to do with them. I am used to `rspec`/`rake` in `ruby`, which looks like this: ![image](https://user-images.githubusercontent.com/12126401/113568935-d5c4ff80-9611-11eb-8f31-c4be1cd56dc0.png) > Likewise I wouldn't want to delete a ticket someone else has created, unless it contains some kind of abuse or spam. We do not have that problem right now though. :-) > Okay, I'll reword the line to avoid deletion as a form of resolution.
sajith (Migrated from github.com) approved these changes 2021-04-06 17:00:23 +00:00
sajith (Migrated from github.com) left a comment
Copy Link

Looks good to me. Perhaps @exarkun and @meejah would want to chime in?

Looks good to me. Perhaps @exarkun and @meejah would want to chime in?
exarkun (Migrated from github.com) requested changes 2021-04-06 18:23:29 +00:00
exarkun (Migrated from github.com) left a comment
Copy Link

Thanks. I left some comments inline.

Also, .documentation news fragments need to have some content. This content gets bundled up with the rest of the news fragment content into the NEWS file at release time.

I'd suggest something like "We added documentation detailing the project's ticket triage process."

Thanks. I left some comments inline. Also, `.documentation` news fragments need to have some content. This content gets bundled up with the rest of the news fragment content into the NEWS file at release time. I'd suggest something like "We added documentation detailing the project's ticket triage process."
docs/ticket-triage.rst
exarkun (Migrated from github.com) commented 2021-04-06 18:17:13 +00:00
Copy Link

Do we want a standing rotation or should we assign the role ad hoc each week?

Do we want a standing rotation or should we assign the role ad hoc each week?
exarkun (Migrated from github.com) commented 2021-04-06 18:18:09 +00:00
Copy Link

Hm I made us all admins but most triage duties probably don't really require this. Maybe creating new milestones requires "roadmap admin" or something like that ... but I'm also not sure creating new milestones is something that should be done by this person during the course of normal triage work.

Hm I made us all admins but most triage duties probably don't really require this. Maybe creating new milestones requires "roadmap admin" or something like that ... but I'm also not sure creating new milestones is something that should be done by this person during the course of normal triage work.
exarkun (Migrated from github.com) commented 2021-04-06 18:21:34 +00:00
Copy Link

Aha. That answers one of my questions above. But we skipped that part today. ;) Perhaps this information could be moved up.

Aha. That answers one of my questions above. But we skipped that part today. ;) Perhaps this information could be moved up.
docs/ticket-triage.rst
@ -0,0 +19,4 @@
- Assign each ticket to a milestone on the Roadmap
- The following situations merit discussion:
- A ticket doesn't have an appropriate milestone and we should create one
- A ticket, in vanishingly rare circumstances, should be deleted
exarkun (Migrated from github.com) commented 2021-04-06 18:20:26 +00:00
Copy Link

Let's see if we can enumerate these circumstances.

  • The ticket is spam
  • The ticket contains sensitive information and harm will come to one or more people if it continues to be distributed

Anything else come to mind for anyone?

Ticket deletion requires "ticket admin" capabilities in trac. We might also want to contemplate the fact that we may switch from trac to a system that doesn't support ticket deletion at all.

Let's see if we can enumerate these circumstances. * The ticket is spam * The ticket contains sensitive information and harm will come to one or more people if it continues to be distributed Anything else come to mind for anyone? Ticket deletion requires "ticket admin" capabilities in trac. We might also want to contemplate the fact that we may switch from trac to a system that doesn't support ticket deletion at all.
meejah (Migrated from github.com) approved these changes 2021-04-10 00:00:34 +00:00
docs/ticket-triage.rst
meejah (Migrated from github.com) commented 2021-04-09 23:56:41 +00:00
Copy Link

I'd say probably more ad-hoc? (because availability etc etc and could encourage new volunteers to take the role)

I'd say probably more ad-hoc? (because availability etc etc and could encourage new volunteers to take the role)
meejah (Migrated from github.com) commented 2021-04-09 23:58:48 +00:00
Copy Link

So could just leave this statement out, you mean? (Maybe just "the Triager needs a Trac account")

So could just leave this statement out, you mean? (Maybe just "the Triager needs a Trac account")
docs/ticket-triage.rst
@ -0,0 +19,4 @@
- Assign each ticket to a milestone on the Roadmap
- The following situations merit discussion:
- A ticket doesn't have an appropriate milestone and we should create one
- A ticket, in vanishingly rare circumstances, should be deleted
meejah (Migrated from github.com) commented 2021-04-10 00:00:19 +00:00
Copy Link

Maybe it's fine as-is: if something seems like it should be deleted, the Triager probably should bring it up for discussion (rather than just deleting it). If it's especially problematic / time-sensitive they could just delete it (but should probably still bring it up).

Maybe it's fine as-is: if something seems like it should be deleted, the Triager probably should bring it up for discussion (rather than just deleting it). If it's especially problematic / time-sensitive they could just delete it (but should probably still bring it up).
Sign in to join this conversation.
Reviewers
No reviewers
sajith
exarkun
meejah
Labels
Clear labels   
Benchmarking and Performance

   
HTTP Storage Protocol

   
Nevow Removal

   
Python 3 Porting

   
not-for-merge
No Label
Benchmarking and Performance
HTTP Storage Protocol
Nevow Removal
Python 3 Porting
not-for-merge
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 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: tahoe-lafs/tahoe-lafs#1032
No description provided.
Delete Branch "dev-guide-ticket-triage"

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?