#10 udpate day to day working with CentOS Infra team
Merged 4 years ago by siddharthvipul1. Opened 4 years ago by siddharthvipul1.
cpe/ siddharthvipul1/docs master  into  master

@@ -5,7 +5,83 @@ 

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

  do the work you are asking us to do.

  

- [NOTE]

- ====

- This document is a work in progress and will be updated soon.

- ====

+ == Our Workflow

+ 

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

+ run?

+   * send an email to `security` @centos.org

+ 

+ . Is your issue CentOS CI Infra or CentOS Infra related?

+   * Follow next step

+ 

+ . File a ticket in link:https://pagure.io/centos-infra/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. Make sure to note if

+   there is a deadline or if this issue blocks you.

+   * Your ticket will be reviewed within 48 hours at most; usually sooner.

+   * There is no need to ping team members or notify us about the newly filed

+     ticket.

+ 

+ . Is your issue/problem urgent? (credentials exposed, CI Infra down, Duffy Pool

+ exhausted etc) or is your issue/problem such that you cannot file a ticket

+ (authentication, no account, ticketing system down)

+   * On IRC (irc.freenode.net) join the `#centos-devel` and state the issue there.

+   * If no answer, follow the next step

+ 

+ 

+ . 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 working 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 otherwise closed, it will be with a explanation from

+   a team member.

+ 

+ . 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 time frame.

+ 

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

+   on.

+   * Watch for progress reports/ticket being marked done.

+ 

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

+   and indicate this.

+   * Go back to the previous step for additional work.

+ 

+ 

+ == General Ticket Considerations

+ 

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

+ back and forth for information.

+ 

+ Make sure your ticket:

+ 

+ * Explains the problem or issue you are having, with URLs where

+   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 is your responsibility as ticket reporter 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 current workload

+ of the team has and how important we think it is. If your ticket

+ is blocking you, make sure you note that in the ticket, but keep in

+ mind that we may already 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 you on IRC for more interactive debugging/testing.

+ 

+ == Direct emails

+ 

+ E-mail 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). So, please avoid direct emails and

+ instead update tickets with any information you want to add.

Couple of questions, otherwise it reads fine :)

rebased onto cf545f0

4 years ago

@pingou
done s/nest/next
for mailing list, It may not be the ideal solution but removed the whole line itself.
Since it's a thing for ticket consideration, left it at that (we need to see if there is a ticket that will create such a discussion first :P) in that case we can recommend on the ticket. So far I can't recall any similar incidence (since there are just consumers who mostly don't care as long as we provide what's needed)

Looks good to me and we can always improve as we need :)

We should spend time defining what the urgency of tickets are, and what they mean to us. Keeping in mind that the service we offer is best effort.

Everything is usually top level urgent to someone opening the ticket, but it should be categorised according to our urgency definition scale.

Everything is usually top level urgent to someone opening the ticket, but it should be categorised according to our urgency definition scale.

Note that I don't think they will have access themselves to set the priorities.

+1 on defining them nonetheless

Can we reuse those used in Fedora infra ?

We should spend time defining what the urgency of tickets are, and what they mean to us. Keeping in mind that the service we offer is best effort.

Some urgent issues are

  • by mistake credentials are exposed in builds (I have seen it happen)
  • Cluster is down/unreachable (or Jenkins is down)
  • Duffy pool is exhausted

If it is something urgent that we do acknowledge as urgent, we do it asap
otherwise, we leave it to triage it the next stand up

rebased onto 6c9337b

4 years ago

Pull-Request has been merged by siddharthvipul1

4 years ago
Metadata