#4 working_with_us: try and make a more easy to understand flow chart.
Merged 4 years ago by pingou. Opened 4 years ago by kevin.
cpe/ kevin/docs workflow-enhanced  into  master

@@ -5,7 +5,40 @@ 

  Your close attention to this document will help both you and us

  do the work you are asking us to do.

  

- == Urgent Issues / Triage of Incoming Issues

+ == Our Workflow

+ 

+ 

+ 0. Is your issue/problem related to security of an application or service we run?

+ -> send email to infra-security@fedoraproject.org

+ 

+ 1. Is your issue/problem urgent? (A important service is down, you need a change asap)

+ or IS your issue/problem such that you cannot file a ticket (authentication, no account, ticketing system down)

+ -> on irc /join #fedora-admin and say '.oncall' and explain the issue to the oncall person.

+ -> If no answer or the oncall person asks you to: go to next step.

+ 

+ 2. File a ticket in https://pagure.io/fedora-infrastructure/issues/ with as much information

+ as you think will be needed to handle your issue. This initial ticket will be made in the 

+ 'Needs review' state. Please note if there is a deadline or this issue blocks you.

+ -> your ticket will be reviewed within 48 hours. (usually sooner)

+ -> There is no need to ping team members or notify us about the newly filed ticket.

+ 

+ 3. your ticket will be triaged by a team member and moved to a new state:

+ -> If it's moved to 'Waiting on asignee' it's waiting for a team member to start work on it.

+ -> If it's moved to 'Waiting on reporter' it means that you need to answer questions posed in the ticket before it can be worked on. 

+ -> If the ticket is closed with 'initiative', See xref:initiatives.adoc[New Initiative Workflow]

+ -> If the ticket is otherwise closed, it will be with a explaination from a team member.

explaination -> explanation

I'll fix this in a subsequent commit

+ 

+ 4. If you have an update to your issue/task or want to know when it might be worked on:

+ -> comment in the ticket adding that information or asking for timeframe. 

+ 

+ 5. When someone is available, your ticket will be assigned to someone to work on. 

+ -> Watch for progress reports/ticket being marked done. 

+ 

+ 6. If the work is not fully completed as required, please re-open the ticket and indicate this.

+ -> go back to step 5 for additional work. 

+ 

+ == The oncall role in our team

+ 

  

  Weekly a team member will be designated “oncall”. You can find this

  person on IRC by using '.oncall' in any of our various IRC channels.
@@ -22,18 +55,7 @@ 

  3. Triages incoming tickets for urgent items that need work outside

  of normal triage process.

  

- == Normal Operation Requests

- 

- All normal operation requests should be filed as tickets, work items will not

- be accepted via private emails or IRC unless the oncall person determines them

- to be urgent.

- 

- == Normal Application Requests

- 

- All normal application bugs should be filed in the upstream tracker for the

- respective application where possible, unless it’s a deployment issue.

- 

- == Larger Projects / Feature Requests

+ == Initiatives

  

  All tasks involving new applications, major deployments, major development work

  or the like will be asked to follow the xref:initiatives.adoc[New Initiative
@@ -41,6 +63,7 @@ 

  

  == General Ticket Considerations

  

+ 

  Please provide as much information as you can in your ticket to avoid

  back and forth for information. If you know your issue is going to

  cause a lot of discussion, start a mailing list thread for that.
@@ -52,13 +75,9 @@ 

  * tells us how important or urgent this is to you.

  * includes any error messages or output you see.

  

- It’s up to you as ticket filer to follow up on your ticket, provide information

- that is asked for and keep us aware of any urgency you may have, do not simply

- file and forget your ticket.

- 

- If you are unsure where to file a ticket or which information you should

- provide, please ask the oncall person or mail the team at

- https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/

+ It's up to you as ticket filer to follow your ticket, provide information

+ that is asked for and keep us aware of any urgency you may have, do not

+ simply file and forget your ticket.

  

  Your ticket may take a while to process, depending on the work

  that the team has and how important we think it is. If your ticket
@@ -67,6 +86,7 @@ 

  

  == IRC

  

+ 

  IRC is a great way to communicate, but please do not ping team members directly.

  Instead, update your ticket with any new information you have and when the

  team member(s) working on that issue have time/availability they may contact
@@ -74,13 +94,17 @@ 

  

  == Direct emails

  

+ 

  Email is also a great communication method, but if you mail work items or

- information to one person directly, they cannot easily hand off the issue, you

- must wait for them to have time to address the issue (when others could perhaps

- have already solved it, etc). Therefore, please avoid direct emails and update

- tickets with any information you want to add instead.

+ information to one person directly, they cannot easily hand off the issue,

+ you must wait for them to have time to address the issue (when others could

+ perhaps have already solved it, etc). So, please avoid direct emails and instead

+ update tickets with any information you want to add.

  

  == RFC 1149

  

+ 

  link:https://tools.ietf.org/html/rfc1149[Pidgeons are too slow] for most work

- items, update tickets instead (and thanks for reading this far).

+ items, instead update tickets.

+ 

+ Thank you for reading this entire document!

I tried to make this more simple and clear and a flow/decision document for users.

Signed-off-by: Kevin Fenzi kevin@scrye.com

Let's give ourselves some breathing room and say 36 hours, or maybe even 48 hours for example when most of us travel to a conference I figure it can take that long.

  • -> The other close status should self-sufficient and will most often be explain additionally by a comment from the person closing the ticket.

Let's give ourselves some breathing room and say 36 hours, or maybe even 48 hours for example when most of us travel to a conference I figure it can take that long.

Sure, lets say 48.

-> The other close status should self-sufficient and will most often be explain additionally by a comment from the person closing the ticket.

good idea, added a slightly re-worded version of this.

your?

reworked this.

rebased onto e1f0659

4 years ago

explaination -> explanation

I'll fix this in a subsequent commit

Pull-Request has been merged by pingou

4 years ago
Metadata