From 3ddc3e85e32d10cee75d11061fea0686eac9b534 Mon Sep 17 00:00:00 2001 From: Pierre-Yves Chibon Date: Aug 02 2019 12:43:06 +0000 Subject: Move the cpe modules to ROOT Signed-off-by: Pierre-Yves Chibon --- diff --git a/antora.yml b/antora.yml index ec45506..624d640 100644 --- a/antora.yml +++ b/antora.yml @@ -9,8 +9,8 @@ title: Community Platform Engineering Team # <---- PLEASE MODIFY version: master # We encourage you to name the index page as "index.adoc". If you absolutely have to use a different name, please reflect it here. You can ignore this field otherwise. -start_page: cpe:index +start_page: ROOT:index # This lists all the menu definitions of your component. nav: -- modules/cpe/nav.adoc +- modules/ROOT/nav.adoc diff --git a/modules/ROOT/assets/images/our_missions.jpg b/modules/ROOT/assets/images/our_missions.jpg new file mode 100644 index 0000000..e467178 Binary files /dev/null and b/modules/ROOT/assets/images/our_missions.jpg differ diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc new file mode 100644 index 0000000..45d71a9 --- /dev/null +++ b/modules/ROOT/nav.adoc @@ -0,0 +1,7 @@ +* xref:working_with_us.adoc[Working with CPE] +** xref:day_to_day_fedora.adoc[Day to day in Fedora] +** xref:day_to_day_centos.adoc[Day to day in CentOS] +** xref:initiatives.adoc[Initiatives] +** xref:sle.adoc[SLE] +*** xref:sle_services.adoc[Services] +* xref:about.adoc[About the Team] diff --git a/modules/ROOT/pages/about.adoc b/modules/ROOT/pages/about.adoc new file mode 100644 index 0000000..1820f46 --- /dev/null +++ b/modules/ROOT/pages/about.adoc @@ -0,0 +1,44 @@ += About the team + +In 2017 the Fedora Engineering team merged with the CentOS Engineering team +to form what is now called the Community Platform Engineering (CPE) team. + +For the team members, the day to day work did not change much. + +The members working on Fedora are still fully dedicated to work on the +Fedora Project, and those working on CentOS are still fully dedicated to +CentOS. On both projects its members are involved in infrastructure, release +engineering, and design. However, it brought the two infrastructures and +teams closer to each other, allowing for more collaboration between them. + +There are 20 people on this consolidated team. The breakdown looks like this: + +* In Fedora: + +** 3 dedicated system administrators +** 5 dedicated developers +** 1 doing both development and system administration +** 1 doing both release engineering and system administration +** 1 person dedicated to Fedora CoreOS +** 2 release engineers +** 1 person dedicated to documentation +** 1 designer + +* In CentOS: +** 1 system administrator +** 2 doing both development and system administration +** 1 dedicated to the build systems + +* 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 +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 +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 +work with us] for small and large tasks. Following this document makes it +easier for us to help you. diff --git a/modules/ROOT/pages/day_to_day_centos.adoc b/modules/ROOT/pages/day_to_day_centos.adoc new file mode 100644 index 0000000..f1117fb --- /dev/null +++ b/modules/ROOT/pages/day_to_day_centos.adoc @@ -0,0 +1,8 @@ += 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`. diff --git a/modules/ROOT/pages/day_to_day_fedora.adoc b/modules/ROOT/pages/day_to_day_fedora.adoc new file mode 100644 index 0000000..6038ceb --- /dev/null +++ b/modules/ROOT/pages/day_to_day_fedora.adoc @@ -0,0 +1,112 @@ += 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. + + +== 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. + +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. + + +== 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 +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. + +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'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 +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. + + +== 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 + +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). 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. + +Thank you for reading this entire document! diff --git a/modules/ROOT/pages/index.adoc b/modules/ROOT/pages/index.adoc new file mode 100644 index 0000000..86bd853 --- /dev/null +++ b/modules/ROOT/pages/index.adoc @@ -0,0 +1,53 @@ += The Community Platform Engineering Team + +The Community Platform Engineering Team (CPE) is a Red Hat team dedicated +to the Fedora and CentOS projects where they contribute to the infrastructure +and release engineering. + + +== 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. + +== 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:__ + +* __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/initiatives.adoc b/modules/ROOT/pages/initiatives.adoc new file mode 100644 index 0000000..327dd71 --- /dev/null +++ b/modules/ROOT/pages/initiatives.adoc @@ -0,0 +1,116 @@ += New Initiative Workflow + +:toc: + +This document documents a proposed workflow to get new initiatives onto the CPE backlog. + + +== The Different Steps + +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. +* 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. + + +=== Writing Down a Requirement Document + +The CPE team has link:https://hackmd.io/@pingou/rJd0HaipV[prepared a template] +for you to use to write down your requirement document. + +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? + +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. + + +=== Proposing a New Initiative + +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 + + +=== 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. + + +=== 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. + +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 +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. + +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). + +If the initiative is not accepted by the CPE team, the ticket will be +closed as rejected with some explanations 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 +that will be worked on. + + +== 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 +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 new file mode 100644 index 0000000..d7d71a2 --- /dev/null +++ b/modules/ROOT/pages/mission_statement.adoc @@ -0,0 +1,45 @@ += 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 new file mode 100644 index 0000000..3ec79d2 --- /dev/null +++ b/modules/ROOT/pages/sle.adoc @@ -0,0 +1,154 @@ += 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. + + +== Primary Business Hours + +Fedora Infrastructure's primary business hours are aligned with the work +schedule of Red Hat Inc. Normal hours should be seen as during Monday +through Friday 1400 UTC to 2300 UTC with US national holidays and a 2 week +end of year closure affecting staffing and response times. + +Services outside of primary business hours are done on call and depend on +the availability of staff. + +== Roles and Responsibilities + +=== Fedora Infrastructure to Community + +* To have staff present and available in appropriate IRC channels to answer + questions during primary hours. +* To have particular staff on-call during off hours so that community + members can contact for Critical and Important services. +* 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. +* Move items which can not be resolved within a reasonable time to future + feature requests or close out. + +=== Community Member to Fedora Infrastructure + +* Give 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 + +=== Fedora Infrastructure to Fedora Infrastructure + +* Have a clear schedule of reachable hours. +* Set and take regular vacation time to be rested. +* Rotate through days on-call in IRC and tickets. +* If adding a new service, be available outside of normal business hours to + help debug problems. +* Follow procedures and checklists when adding or updating services. +* Help with regular audits of the documentation + +== Definition of Service Priorities + +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". + +== Limitations on Support + +* Some services that are associated with Fedora are provided by third + parties. Changes and outages which affect them are outside the control + of Fedora Infrastructure. +* Fedora Infrastructure will prioritize issues and requests that affect + multiple people or teams over a smaller group or individual. +* Fedora Infrastructure has limited budget and hours. Requests and features + will be prioritized to fit within those. +* Fedora Infrastructure is bound by the laws and regulations of the United + States of America. This means that certain requests, changes and problems + are outside the ability of members to deal with. + +== 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. + +* **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 + 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 Availability**: Systems or applications are available 24x7 + with no planned or unplanned outages. This is a combination of high + 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 + staff available to help deal with issues with systems, services, and + applications. Also known as "Regular Business Hours" + +* **Outage Hours**: Total number of hours of outage considered normal for + calculating achieved availability. + +* **Response Time**: The time between the users notification of the problem + and when the help desk will begin to work on that problem. + +* **Resolution Update**: The frequency of updates to tickets + +== Estimated Time of Resolution: + +By priority Levels: + +* **Emergency**: Problems which are site wide, and affect the core functions + of the project. + +* **Urgent**: Problems which affect multiple functions and groups in the + project. + +* **Normal**: Problems which affect a single user from performing needed + duties. + +* **Low**: A request for service, instruction, information that has no + immediate impact on services. diff --git a/modules/ROOT/pages/sle_services.adoc b/modules/ROOT/pages/sle_services.adoc new file mode 100644 index 0000000..5c913cd --- /dev/null +++ b/modules/ROOT/pages/sle_services.adoc @@ -0,0 +1,148 @@ += Services SLE + +Here is the list of our services per SLE level. For memory these levels are +presented in our xref:sle.adoc[SLE Documentation]. + + +WARNING: This document is still a **work in progress**. The services listed +there are at their appropriate level for Fedora but not all of them are under +the responsabilities of the CPE team which is currently not represented here. + + +== Critical + +* DNS +* Bastion ssh +* Authentication/authorization (FAS) https://admin.fedoraproject.org/accounts/ +* Authentication/authorization (Ipsilon) https://id.fedoraproject.org +* Configuration Management (ansible) +* Source control (git) +* Backups +* DHCP/PXE +* IPA + + +== Important + +* Koji https://koji.fedoraproject.org +* Bodhi https://bodhi.fedoraproject.org +* Downloads https://dl.fedoraproject.org/ +* Fedora Souce code https://src.fedoraproject.org/ +* MirrorManager https://admin.fedoraproject.org/mirrormanager +* Nagios https://nagios.fedoraproject.org +* HAProxy https://admin.fedoraproject.org/haproxy/proxy01 +* Postgres databases +* Mysql databases +* Product Definition Center https://pdc.fedoraproject.org/ +* Greenwave +* Fedmsg +* DataGrepper https://apps.fedoraproject.org/datagrepper/ +* Email gateway bastion.fedoraproject.org +* Autosign +* Composer +* Buildhosts +* Docker registry +* Memcached +* Logging +* Basset +* PDC +* resultsdb +* certgetter +* mbs +* odcs + + +== Normal + +* Pagure https://pagure.io +* CI https://ci.centos.org +* The Mailing Lists https://lists.fedoraproject.org +* Wiki https://fedoraproject.org/wiki/Fedora_Project_Wiki +* Documentation +* Notifications https://apps.fedoraproject.org/notifications +* Kerneltest https://apps.fedoraproject.org/kerneltest +* Fedora InfraCloud https://fedorainfracloud.org +* FMN +* FAF +* Beaker +* Freshmaker +* Data Analysis + + +== Low + +* Ambassadors https://fedoraproject.org/membership-map/ambassadors.html +* Asknot http://whatcanidoforfedora.org/ +* Badges https://badges.fedoraproject.org/ +* Blocker Bugs https://qa.fedoraproject.org/blockerbugs/ +* Easyfix https://fedoraproject.org/easyfix/ +* Elections https://apps.fedoraproject.org/#Elections +* FedoCal https://apps.fedoraproject.org/#FedoCal +* Fedora Magazine https://fedoramagazine.org/ +* Fedora People https://fedorapeople.org/ +* GeoIP https://geoip.fedoraproject.org/ +* github2fedmsg https://apps.fedoraproject.org/github2fedmsg +* Mdapi https://apps.fedoraproject.org/mdapi/ +* Meetbot https://apps.fedoraproject.org/#Meetbot +* Nuancier https://apps.fedoraproject.org/#Nuancier +* Paste https://paste.fedoraproject.org +* Release Monitoring (anitya) https://release-monitoring.org/ +* Review Status https://fedoraproject.org/PackageReviewStatus/ +* The Planet https://fedoraplanet.org/ +* Unbound +* Autocloud +* Bugyou +* Gobby +* Keys +* Koschei +* Loopabull +* Hotness +* OpenShift +* statscache +* Packages https://admin.fedoraproject.org/pkgdb/packages/ +* bugzilla2fedmsg +* fed-image +* zanata2fedmsg +* secondary +* freemedia +* pager_server +* bz_review +* websites + + +== Websites + +* fedora-web +* fedora-budget +* fedora-docs +* developer +* whatcanidoforfedora +* membership-map +* zanata +* review-stats +* fedora_owner_change + +== Third Party + +Outside of Fedora Infrastructure to fix. + +* Network connectivity to PHX2/RDU2 +* FreeNode IRC https://freenode.net +* Ask Fedora https://ask.fedoraproject.org/ +* COPR https://copr.fedorainfracloud.org/ +* Retrace https://retrace.fedoraproject.org +* Bugzilla https://bugzilla.redhat.com/ +* Status https://status.fedoraproject.org +* Taskotron https://taskotron.fedoraproject.org/ +* Openqa +* Taiga https://teams.fedoraproject.org/ + +== Deprecated + +* Torrents https://torrent.fedoraproject.org +* Darkserver https://darkserver.fedoraproject.org/ +* PkgDB https://admin.fedoraproject.org/pkgdb/ +* Jenkins https://jenkins.fedorainfracloud.org/ +* summershum +* Tagger https://apps.fedoraproject.org/tagger/ +* Taiga https://taiga.fedorainfracloud.org/ diff --git a/modules/ROOT/pages/working_with_us.adoc b/modules/ROOT/pages/working_with_us.adoc new file mode 100644 index 0000000..4987163 --- /dev/null +++ b/modules/ROOT/pages/working_with_us.adoc @@ -0,0 +1,41 @@ += Working with Community Platform Engineering + +This document explains the basic principles of working with the CPE team. + +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 +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 +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 + + +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] diff --git a/modules/cpe/assets/images/our_missions.jpg b/modules/cpe/assets/images/our_missions.jpg deleted file mode 100644 index e467178..0000000 Binary files a/modules/cpe/assets/images/our_missions.jpg and /dev/null differ diff --git a/modules/cpe/nav.adoc b/modules/cpe/nav.adoc deleted file mode 100644 index 45d71a9..0000000 --- a/modules/cpe/nav.adoc +++ /dev/null @@ -1,7 +0,0 @@ -* xref:working_with_us.adoc[Working with CPE] -** xref:day_to_day_fedora.adoc[Day to day in Fedora] -** xref:day_to_day_centos.adoc[Day to day in CentOS] -** xref:initiatives.adoc[Initiatives] -** xref:sle.adoc[SLE] -*** xref:sle_services.adoc[Services] -* xref:about.adoc[About the Team] diff --git a/modules/cpe/pages/about.adoc b/modules/cpe/pages/about.adoc deleted file mode 100644 index 1820f46..0000000 --- a/modules/cpe/pages/about.adoc +++ /dev/null @@ -1,44 +0,0 @@ -= About the team - -In 2017 the Fedora Engineering team merged with the CentOS Engineering team -to form what is now called the Community Platform Engineering (CPE) team. - -For the team members, the day to day work did not change much. - -The members working on Fedora are still fully dedicated to work on the -Fedora Project, and those working on CentOS are still fully dedicated to -CentOS. On both projects its members are involved in infrastructure, release -engineering, and design. However, it brought the two infrastructures and -teams closer to each other, allowing for more collaboration between them. - -There are 20 people on this consolidated team. The breakdown looks like this: - -* In Fedora: - -** 3 dedicated system administrators -** 5 dedicated developers -** 1 doing both development and system administration -** 1 doing both release engineering and system administration -** 1 person dedicated to Fedora CoreOS -** 2 release engineers -** 1 person dedicated to documentation -** 1 designer - -* In CentOS: -** 1 system administrator -** 2 doing both development and system administration -** 1 dedicated to the build systems - -* 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 -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 -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 -work with us] for small and large tasks. Following this document makes it -easier for us to help you. diff --git a/modules/cpe/pages/day_to_day_centos.adoc b/modules/cpe/pages/day_to_day_centos.adoc deleted file mode 100644 index f1117fb..0000000 --- a/modules/cpe/pages/day_to_day_centos.adoc +++ /dev/null @@ -1,8 +0,0 @@ -= 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`. diff --git a/modules/cpe/pages/day_to_day_fedora.adoc b/modules/cpe/pages/day_to_day_fedora.adoc deleted file mode 100644 index 6038ceb..0000000 --- a/modules/cpe/pages/day_to_day_fedora.adoc +++ /dev/null @@ -1,112 +0,0 @@ -= 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. - - -== 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. - -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. - - -== 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 -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. - -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'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 -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. - - -== 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 - -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). 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. - -Thank you for reading this entire document! diff --git a/modules/cpe/pages/index.adoc b/modules/cpe/pages/index.adoc deleted file mode 100644 index 86bd853..0000000 --- a/modules/cpe/pages/index.adoc +++ /dev/null @@ -1,53 +0,0 @@ -= The Community Platform Engineering Team - -The Community Platform Engineering Team (CPE) is a Red Hat team dedicated -to the Fedora and CentOS projects where they contribute to the infrastructure -and release engineering. - - -== 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. - -== 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:__ - -* __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/cpe/pages/initiatives.adoc b/modules/cpe/pages/initiatives.adoc deleted file mode 100644 index 327dd71..0000000 --- a/modules/cpe/pages/initiatives.adoc +++ /dev/null @@ -1,116 +0,0 @@ -= New Initiative Workflow - -:toc: - -This document documents a proposed workflow to get new initiatives onto the CPE backlog. - - -== The Different Steps - -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. -* 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. - - -=== Writing Down a Requirement Document - -The CPE team has link:https://hackmd.io/@pingou/rJd0HaipV[prepared a template] -for you to use to write down your requirement document. - -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? - -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. - - -=== Proposing a New Initiative - -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 - - -=== 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. - - -=== 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. - -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 -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. - -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). - -If the initiative is not accepted by the CPE team, the ticket will be -closed as rejected with some explanations 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 -that will be worked on. - - -== 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 -to work on more initiatives and bring more beneficial changes to our -communities. diff --git a/modules/cpe/pages/mission_statement.adoc b/modules/cpe/pages/mission_statement.adoc deleted file mode 100644 index d7d71a2..0000000 --- a/modules/cpe/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/cpe/pages/sle.adoc b/modules/cpe/pages/sle.adoc deleted file mode 100644 index 3ec79d2..0000000 --- a/modules/cpe/pages/sle.adoc +++ /dev/null @@ -1,154 +0,0 @@ -= 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. - - -== Primary Business Hours - -Fedora Infrastructure's primary business hours are aligned with the work -schedule of Red Hat Inc. Normal hours should be seen as during Monday -through Friday 1400 UTC to 2300 UTC with US national holidays and a 2 week -end of year closure affecting staffing and response times. - -Services outside of primary business hours are done on call and depend on -the availability of staff. - -== Roles and Responsibilities - -=== Fedora Infrastructure to Community - -* To have staff present and available in appropriate IRC channels to answer - questions during primary hours. -* To have particular staff on-call during off hours so that community - members can contact for Critical and Important services. -* 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. -* Move items which can not be resolved within a reasonable time to future - feature requests or close out. - -=== Community Member to Fedora Infrastructure - -* Give 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 - -=== Fedora Infrastructure to Fedora Infrastructure - -* Have a clear schedule of reachable hours. -* Set and take regular vacation time to be rested. -* Rotate through days on-call in IRC and tickets. -* If adding a new service, be available outside of normal business hours to - help debug problems. -* Follow procedures and checklists when adding or updating services. -* Help with regular audits of the documentation - -== Definition of Service Priorities - -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". - -== Limitations on Support - -* Some services that are associated with Fedora are provided by third - parties. Changes and outages which affect them are outside the control - of Fedora Infrastructure. -* Fedora Infrastructure will prioritize issues and requests that affect - multiple people or teams over a smaller group or individual. -* Fedora Infrastructure has limited budget and hours. Requests and features - will be prioritized to fit within those. -* Fedora Infrastructure is bound by the laws and regulations of the United - States of America. This means that certain requests, changes and problems - are outside the ability of members to deal with. - -== 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. - -* **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 - 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 Availability**: Systems or applications are available 24x7 - with no planned or unplanned outages. This is a combination of high - 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 - staff available to help deal with issues with systems, services, and - applications. Also known as "Regular Business Hours" - -* **Outage Hours**: Total number of hours of outage considered normal for - calculating achieved availability. - -* **Response Time**: The time between the users notification of the problem - and when the help desk will begin to work on that problem. - -* **Resolution Update**: The frequency of updates to tickets - -== Estimated Time of Resolution: - -By priority Levels: - -* **Emergency**: Problems which are site wide, and affect the core functions - of the project. - -* **Urgent**: Problems which affect multiple functions and groups in the - project. - -* **Normal**: Problems which affect a single user from performing needed - duties. - -* **Low**: A request for service, instruction, information that has no - immediate impact on services. diff --git a/modules/cpe/pages/sle_services.adoc b/modules/cpe/pages/sle_services.adoc deleted file mode 100644 index 5c913cd..0000000 --- a/modules/cpe/pages/sle_services.adoc +++ /dev/null @@ -1,148 +0,0 @@ -= Services SLE - -Here is the list of our services per SLE level. For memory these levels are -presented in our xref:sle.adoc[SLE Documentation]. - - -WARNING: This document is still a **work in progress**. The services listed -there are at their appropriate level for Fedora but not all of them are under -the responsabilities of the CPE team which is currently not represented here. - - -== Critical - -* DNS -* Bastion ssh -* Authentication/authorization (FAS) https://admin.fedoraproject.org/accounts/ -* Authentication/authorization (Ipsilon) https://id.fedoraproject.org -* Configuration Management (ansible) -* Source control (git) -* Backups -* DHCP/PXE -* IPA - - -== Important - -* Koji https://koji.fedoraproject.org -* Bodhi https://bodhi.fedoraproject.org -* Downloads https://dl.fedoraproject.org/ -* Fedora Souce code https://src.fedoraproject.org/ -* MirrorManager https://admin.fedoraproject.org/mirrormanager -* Nagios https://nagios.fedoraproject.org -* HAProxy https://admin.fedoraproject.org/haproxy/proxy01 -* Postgres databases -* Mysql databases -* Product Definition Center https://pdc.fedoraproject.org/ -* Greenwave -* Fedmsg -* DataGrepper https://apps.fedoraproject.org/datagrepper/ -* Email gateway bastion.fedoraproject.org -* Autosign -* Composer -* Buildhosts -* Docker registry -* Memcached -* Logging -* Basset -* PDC -* resultsdb -* certgetter -* mbs -* odcs - - -== Normal - -* Pagure https://pagure.io -* CI https://ci.centos.org -* The Mailing Lists https://lists.fedoraproject.org -* Wiki https://fedoraproject.org/wiki/Fedora_Project_Wiki -* Documentation -* Notifications https://apps.fedoraproject.org/notifications -* Kerneltest https://apps.fedoraproject.org/kerneltest -* Fedora InfraCloud https://fedorainfracloud.org -* FMN -* FAF -* Beaker -* Freshmaker -* Data Analysis - - -== Low - -* Ambassadors https://fedoraproject.org/membership-map/ambassadors.html -* Asknot http://whatcanidoforfedora.org/ -* Badges https://badges.fedoraproject.org/ -* Blocker Bugs https://qa.fedoraproject.org/blockerbugs/ -* Easyfix https://fedoraproject.org/easyfix/ -* Elections https://apps.fedoraproject.org/#Elections -* FedoCal https://apps.fedoraproject.org/#FedoCal -* Fedora Magazine https://fedoramagazine.org/ -* Fedora People https://fedorapeople.org/ -* GeoIP https://geoip.fedoraproject.org/ -* github2fedmsg https://apps.fedoraproject.org/github2fedmsg -* Mdapi https://apps.fedoraproject.org/mdapi/ -* Meetbot https://apps.fedoraproject.org/#Meetbot -* Nuancier https://apps.fedoraproject.org/#Nuancier -* Paste https://paste.fedoraproject.org -* Release Monitoring (anitya) https://release-monitoring.org/ -* Review Status https://fedoraproject.org/PackageReviewStatus/ -* The Planet https://fedoraplanet.org/ -* Unbound -* Autocloud -* Bugyou -* Gobby -* Keys -* Koschei -* Loopabull -* Hotness -* OpenShift -* statscache -* Packages https://admin.fedoraproject.org/pkgdb/packages/ -* bugzilla2fedmsg -* fed-image -* zanata2fedmsg -* secondary -* freemedia -* pager_server -* bz_review -* websites - - -== Websites - -* fedora-web -* fedora-budget -* fedora-docs -* developer -* whatcanidoforfedora -* membership-map -* zanata -* review-stats -* fedora_owner_change - -== Third Party - -Outside of Fedora Infrastructure to fix. - -* Network connectivity to PHX2/RDU2 -* FreeNode IRC https://freenode.net -* Ask Fedora https://ask.fedoraproject.org/ -* COPR https://copr.fedorainfracloud.org/ -* Retrace https://retrace.fedoraproject.org -* Bugzilla https://bugzilla.redhat.com/ -* Status https://status.fedoraproject.org -* Taskotron https://taskotron.fedoraproject.org/ -* Openqa -* Taiga https://teams.fedoraproject.org/ - -== Deprecated - -* Torrents https://torrent.fedoraproject.org -* Darkserver https://darkserver.fedoraproject.org/ -* PkgDB https://admin.fedoraproject.org/pkgdb/ -* Jenkins https://jenkins.fedorainfracloud.org/ -* summershum -* Tagger https://apps.fedoraproject.org/tagger/ -* Taiga https://taiga.fedorainfracloud.org/ diff --git a/modules/cpe/pages/working_with_us.adoc b/modules/cpe/pages/working_with_us.adoc deleted file mode 100644 index 4987163..0000000 --- a/modules/cpe/pages/working_with_us.adoc +++ /dev/null @@ -1,41 +0,0 @@ -= Working with Community Platform Engineering - -This document explains the basic principles of working with the CPE team. - -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 -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 -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 - - -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] diff --git a/site.yml b/site.yml index a4dd228..ffcf3fc 100644 --- a/site.yml +++ b/site.yml @@ -1,6 +1,6 @@ site: title: Local Preview - start_page: cpe:cpe:index + start_page: cpe:ROOT:index content: sources: - url: .