Project

General

Profile

Feature #16854

collective sysadmin redmine user

Added by groente 5 months ago. Updated 4 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Infrastructure
Target version:
Start date:
Due date:
% Done:

100%

Feature Branch:
Type of work:
Sysadmin
Blueprint:
Starter:
Affected tool:

Description

we'd like to have a possibility of assigning tickets to the sysadmin team in general.
for this we'd need to:

- create a role user for our team on Redmine
- communicate about it to -summit@ (and in our doc?)
- update or deprecate https://redmine.tails.boum.org/code/projects/tails/issues?query_id=262 and https://redmine.tails.boum.org/code/projects/tails/issues?query_id=267

Associated revisions

Revision 76521039 (diff)
Added by intrigeri 4 months ago

Better document current sysadmin team ticket management (Closes: #16854).

History

#1 Updated by CyrilBrulebois 5 months ago

  • Target version changed from Tails_3.15 to Tails_3.16

#2 Updated by groente 4 months ago

  • Status changed from Confirmed to Needs Validation
  • Assignee changed from groente to Sysadmins

There's now a group Sysadmins to which tickets can be assigned, shall I make a shout out to the world to start using this for requesting sysadmin work instead of making individual assignments?

#3 Updated by intrigeri 4 months ago

There's now a group Sysadmins to which tickets can be assigned,

Woohoo!

shall I make a shout out to the world to start using this for requesting sysadmin work instead of making individual assignments?

Yes, please :) This matches what we decided: "communicate about it to -summit@ (and in our doc?)".

And then we'll have to figure out how we can use this new tool to track our collective plans / to do. So far we had:

Thoughts?

#4 Updated by groente 4 months ago

  • Status changed from Needs Validation to In Progress
  • % Done changed from 0 to 50

intrigeri wrote:

Yes, please :) This matches what we decided: "communicate about it to -summit@ (and in our doc?)".

A shout out to -summit has been sent. I'm unsure where this could be documented in our git repo's. Or did you mean the documentation on our public website?

And then we'll have to figure out how we can use this new tool to track our collective plans / to do. So far we had:

  • https://redmine.tails.boum.org/code/projects/tails/issues?query_id=262 (sysadmin shifts) → do we want to now assign all this kind of work to the "Sysadmins" group, and then adjust the custom query to filter on the assignee? The drawback is that as soon as we assign such a ticket to an individual, it appears in no collective view anymore. So I'm not sure what to do. I suspect we should keep this existing view as-is and create a new one for tickets assigned to Sysadmins.

I'm in favor of keeping this view as-is. Personally, I have no interest in another view for tickets assigned to Sysadmins, as they already appear on my personal page anyway.

I suppose atleast the tickets with no current assignee should be assigned to the group. Apart from that, I see little further relation.

#5 Updated by groente 4 months ago

  • Status changed from In Progress to Needs Validation
  • % Done changed from 50 to 60

groente wrote:

intrigeri wrote:

I suppose atleast the tickets with no current assignee should be assigned to the group. Apart from that, I see little further relation.

That's done now. Anything left to discuss here or shall we close the ticket?

#6 Updated by intrigeri 4 months ago

intrigeri wrote:

Yes, please :) This matches what we decided: "communicate about it to -summit@ (and in our doc?)".

A shout out to -summit has been sent.

\o/

I'm unsure where this could be documented in our git repo's. Or did you mean the documentation on our public website?

I don't remember what we meant when we decided "and in our doc?" during our last meeting. This being said:

And then we'll have to figure out how we can use this new tool to track our collective plans / to do. So far we had:

  • https://redmine.tails.boum.org/code/projects/tails/issues?query_id=262 (sysadmin shifts) → do we want to now assign all this kind of work to the "Sysadmins" group, and then adjust the custom query to filter on the assignee? The drawback is that as soon as we assign such a ticket to an individual, it appears in no collective view anymore. So I'm not sure what to do. I suspect we should keep this existing view as-is and create a new one for tickets assigned to Sysadmins.

I'm in favor of keeping this view as-is. Personally, I have no interest in another view for tickets assigned to Sysadmins, as they already appear on my personal page anyway.

OK. So to make that view keep working, we keep adding stuff to that view via a "Blocks" relationship, right?

I suppose atleast the tickets with no current assignee should be assigned to the group. Apart from that, I see little further relation.

OK!

#7 Updated by groente 4 months ago

intrigeri wrote:

intrigeri wrote:
I'm unsure where this could be documented in our git repo's. Or did you mean the documentation on our public website?

I don't remember what we meant when we decided "and in our doc?" during our last meeting. This being said:

  • I see little value in documenting this only in our own repo.

Agreed.

That does seem like the most sensible spot to document this. Do you feel like updating the text there?

And then we'll have to figure out how we can use this new tool to track our collective plans / to do. So far we had:

  • https://redmine.tails.boum.org/code/projects/tails/issues?query_id=262 (sysadmin shifts) → do we want to now assign all this kind of work to the "Sysadmins" group, and then adjust the custom query to filter on the assignee? The drawback is that as soon as we assign such a ticket to an individual, it appears in no collective view anymore. So I'm not sure what to do. I suspect we should keep this existing view as-is and create a new one for tickets assigned to Sysadmins.

I'm in favor of keeping this view as-is. Personally, I have no interest in another view for tickets assigned to Sysadmins, as they already appear on my personal page anyway.

OK. So to make that view keep working, we keep adding stuff to that view via a "Blocks" relationship, right?

Correct!

#8 Updated by intrigeri 4 months ago

  • Status changed from Needs Validation to In Progress
  • Assignee changed from Sysadmins to intrigeri

That does seem like the most sensible spot to document this. Do you feel like updating the text there?

I will!

#9 Updated by intrigeri 4 months ago

  • Status changed from In Progress to Resolved
  • % Done changed from 60 to 100

Also available in: Atom PDF