From dbbddfb3d128c40a6957243e5f3595265d7cd201 Mon Sep 17 00:00:00 2001 From: Petr Bokoc Date: Aug 11 2019 09:17:18 +0000 Subject: Various markup/style/grammar fixes --- diff --git a/antora.yml b/antora.yml index 624d640..9016a5d 100644 --- a/antora.yml +++ b/antora.yml @@ -3,7 +3,7 @@ name: cpe # <---- PLEASE MODIFY # Title will be visible on the page. -title: Community Platform Engineering Team # <---- PLEASE MODIFY +title: Community Platform Engineering # <---- PLEASE MODIFY # If you don't plan to have multiple versions of the docs (for example, to document multiple versions of some software), you can ignore this field. Otherwise, change "master" to a specific version. version: master diff --git a/modules/ROOT/pages/about.adoc b/modules/ROOT/pages/about.adoc index 1820f46..30d6042 100644 --- a/modules/ROOT/pages/about.adoc +++ b/modules/ROOT/pages/about.adoc @@ -31,12 +31,12 @@ There are 20 people on this consolidated team. The breakdown looks like this: * There is also one additional person working on projects internal to Red Hat -As you can see this team is both quite diverse as well as limited. For -example, we do not have dedicated database adminstrators or network engineers +As you can see, this team is both quite diverse as well as limited. For +example, we do not have dedicated database administrators or network engineers even though most of our application is one or the other when not both. For these reasons we need to be careful on how our limited resources are -spent. The team has therefore defined a xref:mission_statement.adoc[Mission +spent. The team has therefore defined a xref:index.adoc[Mission Statement] for itself, allowing to focus its work in certain areas. We have also written a document explaining xref:working_with_us.adoc[How to diff --git a/modules/ROOT/pages/day_to_day_centos.adoc b/modules/ROOT/pages/day_to_day_centos.adoc index f1117fb..10f66a2 100644 --- a/modules/ROOT/pages/day_to_day_centos.adoc +++ b/modules/ROOT/pages/day_to_day_centos.adoc @@ -1,8 +1,11 @@ +:experimental: = Working with Community Platform Engineering in CentOS - 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. -`This document is a work in progress and should be updated soon`. +[NOTE] +==== +This document is a work in progress and will be updated soon. +==== diff --git a/modules/ROOT/pages/day_to_day_fedora.adoc b/modules/ROOT/pages/day_to_day_fedora.adoc index 6038ceb..a1b7d7e 100644 --- a/modules/ROOT/pages/day_to_day_fedora.adoc +++ b/modules/ROOT/pages/day_to_day_fedora.adoc @@ -1,61 +1,75 @@ +:experimental: = Working with Community Platform Engineering in Fedora 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. - == Our Workflow -1. Is your issue/problem related to security of an application or service we run? -* send email to infra-security@fedoraproject.org - -2. Is your issue/problem urgent? (An 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, freenode, /join #fedora-admin and say _.oncall_ and explain the issue to the oncall person. -* If no answer: -** If you cannot authenticate to `pagure.io`, send an email to `admin` @ fedoraproject.org -** Otherwise: go to next step. - -3. 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. - -4. 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. -* f 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. - -5. 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. - -6. When someone is available, your ticket will be assigned to someone to work on. -* Watch for progress reports/ticket being marked done. - -7. If the work is not fully completed as required, please re-open the ticket and indicate this. -* go back to step 6 for additional work. +. Is your issue/problem related to security of an application or service we +run? + * send an email to `infra-security` @ fedoraproject.org + +. Is your issue/problem urgent? (An 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 (irc.freenode.net) join the `#fedora-admin` channel, say _.oncall_, + and explain the issue to the oncall person. + * If no answer: + ** If you cannot authenticate to link:https://pagure.io/[], send an email + to `admin` @ fedoraproject.org + ** Otherwise: go to next step. + +. File a ticket in link: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. 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. + +. 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 closed with _initiative_, see + xref:initiatives.adoc[New Initiative Workflow]. + * 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. + +== The "Oncall" Role in Our Team + +One CPE team member is always designated “oncall”. The assigned person changes +every week. You can find who the currently assigned person is on IRC by using +`.oncall` in any of our various IRC channels, such as `#fedora-admin` on +FreeNode. - -== 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. When available, this person: -1. Accepts urgent work items for the team, for example a important -or high SLE service is down or causing issues. A ticket should -be filed by the reporter or the oncall to track this work in any case. +. Accepts urgent work items for the team, such as an important + or high SLE service being down or causing issues. A ticket should + be filed by the reporter or the oncall person to track this work in any case. -2. Shields other team members from distracting pings and less -urgent tickets, deciding when an issue is important enough to -interrupt another team member. - -3. Triages incoming tickets for urgent items that need work outside -of normal triage process. +. Shields other team members from distracting pings and less + urgent tickets, deciding when an issue is important enough to + interrupt another team member. +. Triages incoming tickets for urgent items that need work outside + of normal triage process. == Initiatives @@ -63,7 +77,6 @@ All tasks involving new applications, major deployments, major development work or the like will be asked to follow the xref:initiatives.adoc[New Initiative 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 @@ -72,41 +85,42 @@ cause a lot of discussion, start a mailing list thread for that. 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. +* 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'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. +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 work -that the team has and how important we think it is. If 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 be working on tickets that are blocking more people. - +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. - +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 -Email is also a great communication method, but if you mail work items or +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. - +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, instead update tickets. +link:https://tools.ietf.org/html/rfc1149[Pigeons are too slow] for most work +items, and require facilities (e.g. dovecots) that most team members do not +have. Even if the oncall member does have a free dovecot, feed, and is trained +in handling carrier pigeons, sending a pigeon to a single team member has the +same problems as using IRC or email for the same purpose, which means tickets +are still the correct way to report problems. -Thank you for reading this entire document! +In other words, please don't send us any birds. diff --git a/modules/ROOT/pages/index.adoc b/modules/ROOT/pages/index.adoc index 54708fd..5e54c9f 100644 --- a/modules/ROOT/pages/index.adoc +++ b/modules/ROOT/pages/index.adoc @@ -1,3 +1,4 @@ +:experimental: = The Community Platform Engineering Team The Community Platform Engineering Team (CPE) is a Red Hat team dedicated @@ -19,25 +20,25 @@ image::our_missions.jpg[Our Mission,500,500] * **Application maintenance**: For the applications that we maintain, we work on bug fixes, new features and community development. * **Initiatives**: For a limited time and scope we dedicate some of our - engineers and adminstrators to initiatives deemed important and beneficial to - the communities we are involved in. + engineers and administrators to initiatives deemed important and beneficial +to the communities we are involved in. One of the key challenges this team faces is balancing these three axes. -For this reason, we worked on the following Mission Statement. +For this reason, we developed the following Mission Statement. -== Our responsibilities +== Our Responsibilities Our responsibilities are scoped in our mission statement: === Our Mission Statement __The Community Platform Engineering Team is responsible for the -infrastructure and services that support developing, building, and -releasing of Fedora and CentOS platform artifacts and deliverables, -including:__ +infrastructure and services that support developing, building, and releasing +of Fedora and CentOS platform artifacts and deliverables, including:__ * __Hosting, automating, monitoring and maintaining infrastructure components__ -* __Service monitoring and lifecycle management of services hosted within our infrastructure__ +* __Service monitoring and lifecycle management of services hosted within our + infrastructure__ * __Feature development for infrastructure-related initiatives__ * __Tooling to enable all of the above__ diff --git a/modules/ROOT/pages/initiatives.adoc b/modules/ROOT/pages/initiatives.adoc index 327dd71..e361c5f 100644 --- a/modules/ROOT/pages/initiatives.adoc +++ b/modules/ROOT/pages/initiatives.adoc @@ -1,42 +1,42 @@ -= New Initiative Workflow - +:experimental: :toc: += New Initiative Workflow -This document documents a proposed workflow to get new initiatives onto the CPE backlog. - +This document documents a proposed workflow to get new initiatives onto the +CPE backlog. -== The Different Steps +== The Process The process to bring something to the attention of the CPE team consists of several steps: * Propose a new initiative; this proposal gives the “what” and “why” of the work requested. -* Based on the proposal, the team then decides if it fits its mission - statement and thus if it is worth being pursued by the team, or if this work - falls under the responsibility of someone else. -* For work considered in scope, the CPE team together with the submitter work - on figuring out the best approach to fulfill the request. +* The team will review and discuss the proposal and determine whether it fits + its mission statement and thus if it is worth being pursued by the team, or + whether this work falls under the responsibility of someone else. +* If the CPE team determines the proposal to be in line with the + xref:index.adoc[mission statement], the team will work together with the + submitter on figuring out the best approach to fulfill the request. * Based on the estimated amount of work, the initiatives currently in - progress, priorities, and return on investment, the CPE team decides - whether they can commit to this initiative, and if so, a rough timeline - for it. - + progress, priorities, and return on investment, the CPE team decides whether + they can commit to this initiative, and if so, a rough timeline for it. -=== Writing Down a Requirement Document +=== Writing Down a Requirements Document -The CPE team has link:https://hackmd.io/@pingou/rJd0HaipV[prepared a template] -for you to use to write down your requirement document. +The CPE team has prepared a link:https://hackmd.io/@pingou/rJd0HaipV[template] +for you to use to write down your requirements document. +//TODO: make sure this gets updated when the GDoc is This document is divided into two parts, the first part is yours to fill. -It is basically the what and why of your request: - -* What do you want the CPE team to work on? -* Why do you think it is worth for the CPE team to work on it? +It is basically the _what_ and _why_ of your request: -The second part will be filled out later by you and the CPE team once your -proposal has been accepted based on its subject and the specified reason. +* _What_ do you want the team to work on? +* _Why_ do you think it is worth doing? +Once your proposal has been accepted based on its subject and the specified +reason, the team will contact you and you will fill out the second part of +the template together. === Proposing a New Initiative @@ -44,73 +44,67 @@ Once you have written down your requirement document, submit it to the CPE team for review. To do this, simply open a ticket on the link:https://pagure.io/cpe/initiatives-proposal[CPE-initiatives issue tracker]. -You will be asked a few things in this ticket: - -- a link to your requirement document -- potential dependencies for this initiative (dependencies on people or - other initiatives) -- potential deadlines that could impact the initiative +The ticket should contain the following items: +* A link to your requirements document. +* Potential dependencies for this initiative (dependencies on people or other + initiatives). +* Potential deadlines that could impact the initiative. === First Decision Point: Is This Initiative for the CPE Team? -Based on these information the CPE team will decide if this initiative is in -scope for it (i.e. does it fit its xref:mission_statement.adoc[Mission -Statement]), but also if there is a clear benefit for the communities the CPE -team is involved in. - -If your initiative doesn’t fit in the purview of the CPE team, it does not mean -your challenge is not worth pursuing but that the CPE team has limited -resources and needs to be careful on how they are spent. - -Every two weeks, the CPE team will meet to go over the proposed initiatives. At this -point, the CPE team will decide if it accepts your initiative or, if necessary, -appoint someone who will work with you to polish this document, improve the -user-story, and discuss with you what is in scope and what isn’t. +Based on the information provided in the ticket, the CPE team will consider +whether the initiative is in scope of the xref:index.adoc[Mission Statement], +and if there is a clear benefit for the communities the CPE team is involved +in. If your initiative does not fit in the process outline of the CPE team, +it does not mean your challenge is not worth pursuing - but that the CPE team +has limited resources and needs to be careful on how they are spent. +Every two weeks, the CPE team will meet to go over the proposed initiatives. +At this point, the CPE team will decide if it accepts your initiative, or, if +necessary, appoint someone who will work with you to polish this document, +improve the user-story, and discuss with you what is in scope and what isn’t. === Figuring out the Technical Solution -If your proposal fits for the CPE team, you will be asked to collaborate with a -team representative to figure out the best technical solution to answer the -use-case and user stories set in your requirements document. - -This step may involve requesting feedback from the communities affected by this -change. +If your proposal is in line with CPE's mission, you will be asked to +collaborate with a team representative to figure out the best technical +solution to answer the use-case and user stories set in your requirements +document. This step may involve requesting input from any communities +affected by this change. The second part of the requirement document should be kept up to date to -reflect the technical solution of choice and, if applicable, document other -approaches and why they were rejected (this could also be stored in a different +reflect the technical solution of choice, and, if applicable, document other +approaches and why they were rejected (this may also be stored in a different place linked from the requirement document). - === Final Decision and Prioritization Finally, once the two parts of the requirement document have been filled, -the CPE team and its stakeholder will be consulted to decide if the -initiative is worth doing and what its priority status should be on the -backlog of the team. +the CPE team and its stakeholders will be consulted to decide if the +initiative is worth doing and what its priority status should be in the team's +backlog. -If the initiative is approved, the ticket will be closed as accepted and an +If the initiative is approved, the ticket will be closed as _accepted_ and an epic will be created in the link:https://teams.fedoraproject.org/project/pingou-cpe-dev-1/epics[CPE Taiga board]. It will then be up to the team working on this epic to track their work in Taiga or elsewhere (which should be documented in the epic). +//TODO: Fix the above link If the initiative is not accepted by the CPE team, the ticket will be -closed as rejected with some explanations as to why. +closed as _rejected_ with an explanation as to why. Every quarter of the year, the CPE team will meet to plan their work for the -next one. During this meeting, the team will go over the proposed and accepted -initiatives, weigh them against each other, prioritize them and pick the ones +next one. During this meeting, the team will go over the proposed and accepted +initiatives, weigh them against each other, prioritize them, and pick the ones that will be worked on. +== Final Notes -== Conclusions - -This new workflow will be a change from how the CPE team has worked until now. -Its core idea is to maximize the output of the team to the community. We are -not able to accept everything and anything and we want to make sure that what -we accept is properly limited in scope and time. Hopefully this will allow us +This new workflow is a change from how the CPE team has worked until now. +The core idea is to maximize the output of the team to the community. We are +not able to accept everything and anything, and we want to make sure that what +we accept is properly limited in scope and time. Hopefully this will allow us to work on more initiatives and bring more beneficial changes to our communities. diff --git a/modules/ROOT/pages/mission_statement.adoc b/modules/ROOT/pages/mission_statement.adoc deleted file mode 100644 index d7d71a2..0000000 --- a/modules/ROOT/pages/mission_statement.adoc +++ /dev/null @@ -1,45 +0,0 @@ -= The CPE Team Mission - -== Our Mission - -Our mission rests on three axes: - -.Our Mission -[#img-mission] -[caption="Figure 1: "] -image::our_missions.jpg[Our Mission,500,500] - -* **Infrastructure**: To provide power and ping to the different systems that - are used by our community. -* **Application maintenance**: For the applications that we maintain, we work - on bug fixes, new features and community development. -* **Initiatives**: For a limited time and scope we dedicate some of our - engineers and adminstrators to initiatives deemed important and beneficial to - the communities we are involved in. - -One of the key challenges this team faces is balancing these three axes. -For this reason, we worked on the following Mission Statement. - - -== What Is Our Mission Statement? - -__The Community Platform Engineering Team is responsible for the -infrastructure and services that support developing, building, and -releasing of Fedora and CentOS platform artifacts and deliverables, -including:__ - -* __Hosting, automating, monitoring and maintaining infrastructure components__ -* __Service monitoring and lifecycle management of services hosted within our infrastructure__ -* __Feature development for infrastructure-related initiatives__ -* __Tooling to enable all of the above__ - - -== Why a Mission Statement? - -A mission statement means the team shares a common vision about what our -work is or should be. It gives us clear boundaries for our work and it -helps us having a critical view on our work (current or in the future): “Does -this fit our mission statement?”. With this in mind we can focus on bringing -more value to the community. In other words, we want to maximize our value and -impact in a targeted mission rather than having limited impact on a broad -spectrum. diff --git a/modules/ROOT/pages/sle.adoc b/modules/ROOT/pages/sle.adoc index 3ec79d2..14253b8 100644 --- a/modules/ROOT/pages/sle.adoc +++ b/modules/ROOT/pages/sle.adoc @@ -1,10 +1,12 @@ +:experimental: +:toc: +//TODO: this file keeps talking about Fedora Infra. We should either change it to CPE, or have a separate SLE doc for CentOS if there's a difference in SLEs. = Service Level Expectations -The CPE team does not have any agreement, or contract about the availability -of its different services. However, we do try our best to keep the services -running and as a result you can have some expectations as to what we will -do to this extent. - +The CPE team does not have any formal agreement or contract regarding the +availability of its different services. However, we do try our best to keep +services running, and as a result, you can have some expectations as to what +we will do to this extent. == Primary Business Hours @@ -27,18 +29,18 @@ the availability of staff. * Interact with community members with respect and courtesy. * Work with community members to get accurate and thorough documentation of incidents, problems, or feature requests. -* When possible resolve the problem as soon as acknowledged. -* Communicate clearly estimated resolution times. +* Resolve reported problems as soon as acknowledged if possible. +* Clearly communicate estimated resolution times. * Move items which can not be resolved within a reasonable time to future feature requests or close out. -=== Community Member to Fedora Infrastructure +=== Community Members to Fedora Infrastructure -* Give full and detailed reports of the problem or requested service. +* Provide full and detailed reports of the problem or requested service. * Provide clear and complete contact information and times when available. * Leave alternative contacts who can also be available in case of vacation or other emergencies. -* When contacted by Fedora IT, respond back within 5 business days +* When contacted by Fedora IT, respond back within 5 business days. === Fedora Infrastructure to Fedora Infrastructure @@ -52,34 +54,35 @@ the availability of staff. == Definition of Service Priorities -The general design of service priorities is that of concentric circles where +The general design of service priorities is that of concentric circles, where items rely on services in their own circle or a circle below them. - -1. Critical services are ones which Fedora Infrastructure will work on 24x7 - with 52 week coverage if an unplanned outage occurs. Services will be - configured to be highly available with an estimated planned/unplanned - uptime of 95%. Response time should be within 1 hour. -2. Important services are ones which Fedora Infrastructure will work to be - available 24x7 with 50 week coverage. Response times during primary hours - should be 1 hour and outside of it should be 4 hours. -3. Normal services are ones which Fedora Infrastructure will work to be - available during primary work hours. Problems outside of these hours will - be looked at as people are available. The services may be available - outside of these but are of a lower priority than important services. -4. Low priority services are ones which are not critical or important for - the primary function of Fedora Infrastructure. They will be worked on and - looked at during primary business hours. Response times should be within - 1 business day. -5. Third Party services are ones which Fedora Infrastructure has outsourced - tools and services to. Uptimes, service hours, and coverage are dictated - by the third party. Depending on the type of problem, Fedora Infrastructure - will act as an intermediary or in the case of tools like retrace and COPR - direct the user to talk with the service owners. -6. Deprecated services are ones which Fedora Infrastructure are no longer - putting resources into. This may be because the project has completed its - mission, the upstream software is dead, or the original reasons for the - product are available. Problems with these services will be looked at - during primary business hours. Responses may be mostly "Will Not Fix". +//TODO: could use an image + +. *Critical* services are ones which Fedora Infrastructure will work on 24x7 + with a 52 week coverage if an unplanned outage occurs. Services will be + configured to be highly available with an estimated planned/unplanned + uptime of 95%. Response time should be within 1 hour. +. *Important* services are ones which Fedora Infrastructure will work to be + available 24x7 with a 50 week coverage. Response times during primary hours + should be 1 hour, and outside of it should be 4 hours. +. *Normal* services are ones which Fedora Infrastructure will work to be + available during primary work hours. Problems outside of these hours will + be looked at as people are available. The services may be available + outside of these but are of a lower priority than important services. +. *Low priority* services are ones which are not critical or important for + the primary function of Fedora Infrastructure. They will be worked on and + looked at during primary business hours. Response times should be within + 1 business day. +. *Third Party* services are ones which Fedora Infrastructure has outsourced + tools and services to. Uptimes, service hours, and coverage are dictated + by the third party. Depending on the type of problem, Fedora Infrastructure + will act as an intermediary, or in the case of tools like retrace and COPR, + direct the user to talk with the service owners. +. *Deprecated* services are ones which Fedora Infrastructure are no longer + putting resources into. This may be because the project has completed its + mission, the upstream software is dead, or the original reasons for the + product are available. Problems with these services will be looked at + during primary business hours. Responses may be mostly "Will Not Fix". == Limitations on Support @@ -96,36 +99,38 @@ items rely on services in their own circle or a circle below them. == Glossary -* **Planned outage**: A planned outage is one that is announced with enough - time to give most user's the ability to plan around it. +* **Planned outage**: A planned outage is one that is announced sufficiently + ahead of time to allow most users to plan around it. * **Unplanned outage**: An outage that occurs suddenly without proper allowance for users to plan around it. -* **Scheduled outage**: An outage which has been scheduled to occur but may +* **Scheduled outage**: An outage which has been scheduled to occur, but may not have been announced with enough time for users to plan around it. * **High Availability**: Systems are available during specified operating hours with any unplanned outages 'masked' by other tools. -* **Continuous Operations**: Systems are available 24 hours a day, 7 days a - week with no scheduled outages. Unplanned outages are possible during this time. +* **Continuous Operations**: Systems are available 24 hours a day, 7 days + a week, with no scheduled outages. Unplanned outages are possible during + this time. * **Continuous Availability**: Systems or applications are available 24x7 with no planned or unplanned outages. This is a combination of high - availability and continuous operations. + availability and continuous operations. * **Level of availability**: - [options="header"] - |====================================== - |Percentage | Max outage time per day | - | 90% | 144.0 minutes | - | 95% | 72.0 minutes | - | 99% | 14.4 minutes | - | 99.9% | 1.4 minutes | - |====================================== - -* **Commited Hours of Availability**: Hours that an organization will have + +[options=header] +|=== +|Percentage | Max outage time per day +| 90% | 144.0 minutes +| 95% | 72.0 minutes +| 99% | 14.4 minutes +| 99.9% | 1.4 minutes +|=== + +* **Committed Hours of Availability**: Hours that an organization will have staff available to help deal with issues with systems, services, and applications. Also known as "Regular Business Hours" @@ -138,7 +143,7 @@ items rely on services in their own circle or a circle below them. * **Resolution Update**: The frequency of updates to tickets == Estimated Time of Resolution: - +//TODO: this is missing the actual times By priority Levels: * **Emergency**: Problems which are site wide, and affect the core functions diff --git a/modules/ROOT/pages/working_with_us.adoc b/modules/ROOT/pages/working_with_us.adoc index 4987163..29ba93c 100644 --- a/modules/ROOT/pages/working_with_us.adoc +++ b/modules/ROOT/pages/working_with_us.adoc @@ -1,41 +1,45 @@ +:experimental: = Working with Community Platform Engineering This document explains the basic principles of working with the CPE team. +These rules are necessary to allow the team to operate efficiently and to +allow us to plan our work. The general rules are: * Do not ping a single person - ++ By doing this you reduce the number of people having access to your request drastically, meaning, if that person is busy with something else, your request may take much longer to be processed. * If it is not in a ticket, it did not happen - -We need to have everything in tickets. This helps sharing knowledge within -the team but also tracking issues and potentially find the ones that are -recurring frequently and may thus be an indicator of something we need to -fix. - -Even if you have discussed something on IRC or in a corridor with someone ++ +We need to have everything in tickets. This helps us share knowledge within +the team, efficiently track our workload, and identify recurring issues which +may be indicative of an underlying problem we need to fix in a more systemic +manner. ++ +Even if you have discussed something on IRC, or in a corridor with someone in the team, you want to log the discussion and its outcome in a ticket so -we can get back to it in 2 months or 3 when we need to investigate why this +we can get back to it later when we need to investigate why this change was made. * When you cannot open a ticket - ++ There are a few cases where it is acceptable to send an email or to reach directly to people, for example if you cannot access or authenticate to the ticket tracking system :) - ++ In this case, you do not want to send your email or ping a single person (cf the first point above). ++ +- In Fedora, you can use the email `admin` @ fedoraproject.org +- In CentOS, you can contact the sysadmins on the `#centos-devel` channel on `irc.freenode.net` -- In Fedora, you can use the email: `admin` @ fedoraproject.org -- In CentOS, you can contact the sysadmins on the `#centos-devel` channel on irc.freenode.net +Both projects have their own, additional, processes for their day to day work, +which you can find in: +- xref:day_to_day_fedora.adoc[Day to day for Fedora] -Both projects have their own, additional, processes for their day to day work, -you can find them there: -- xref:day_to_day_fedora.adoc[for Fedora] -- xref:day_to_day_centos.adoc[for CentOS] +- xref:day_to_day_centos.adoc[Day to day for CentOS]