cle/docs
36
0
Fork 0
Code Issues 3 Pull requests Projects Releases Packages Wiki Activity Actions

working_with_us: try and make a more easy to understand flow chart.

Browse source 
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
This commit is contained in:
Kevin Fenzi 2019-07-26 12:26:33 -07:00
commit e1f0659b7d
1 changed files with 49 additions and 25 deletions
Download patch file Download diff file Expand all files Collapse all files

74
modules/cpe/pages/working_with_us.adoc
View file

@ -5,7 +5,40 @@ This document explains how to efficiently work with the CPE team.
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.
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 @@ interrupt another team member.
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 @@ Workflow]. It will then be scoped and prioritized from there.
== 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 @@ possible to the services or applications involved.
* 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 @@ mind that we may be working on tickets that are blocking more people.
== 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 @@ you on IRC for more interactive debugging/testing.
== 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!