Merge pull request #25162 from mikebrow/devel-tree-80col-updates-C

docs/devel/issues.md

@@ -31,34 +31,62 @@ Documentation for other releases can be found at
 <!-- END STRIP_FOR_RELEASE -->
 
 <!-- END MUNGE: UNVERSIONED_WARNING -->
-GitHub Issues for the Kubernetes Project
-========================================
 
-A quick overview of how we will review and prioritize incoming issues at https://github.com/kubernetes/kubernetes/issues
+## GitHub Issues for the Kubernetes Project
 
-Priorities
-----------
+A quick overview of how we will review and prioritize incoming issues at
+https://github.com/kubernetes/kubernetes/issues
 
-We use GitHub issue labels for prioritization.  The absence of a
-priority label means the bug has not been reviewed and prioritized
-yet.
+### Priorities
 
-We try to apply these priority labels consistently across the entire project, but if you notice an issue that you believe to be misprioritized, please do let us know and we will evaluate your counter-proposal.
+We use GitHub issue labels for prioritization. The absence of a priority label
+means the bug has not been reviewed and prioritized yet.
 
-- **priority/P0**: Must be actively worked on as someone's top priority right now. Stuff is burning. If it's not being actively worked on, someone is expected to drop what they're doing immediately to work on it. TL's of teams are responsible for making sure that all P0's in their area are being actively worked on.  Examples include user-visible bugs in core features, broken builds or tests and critical security issues.
-- **priority/P1**: Must be staffed and worked on either currently, or very soon, ideally in time for the next release.
-- **priority/P2**: There appears to be general agreement that this would be good to have, but we don't have anyone available to work on it right now or in the immediate future. Community contributions would be most welcome in the mean time (although it might take a while to get them reviewed if reviewers are fully occupied with higher priority issues, for example immediately before a release).
-- **priority/P3**: Possibly useful, but not yet enough support to actually get it done. These are mostly place-holders for potentially good ideas, so that they don't get completely forgotten, and can be referenced/deduped every time they come up.
+We try to apply these priority labels consistently across the entire project,
+but if you notice an issue that you believe to be incorrectly prioritized,
+please do let us know and we will evaluate your counter-proposal.
 
-Milestones
-----------
+- **priority/P0**: Must be actively worked on as someone's top priority right
+now. Stuff is burning. If it's not being actively worked on, someone is expected
+to drop what they're doing immediately to work on it. Team leaders are
+responsible for making sure that all P0's in their area are being actively
+worked on. Examples include user-visible bugs in core features, broken builds or
+tests and critical security issues.
 
-We additionally use milestones, based on minor version, for determining if a bug should be fixed for the next release. These milestones will be especially scrutinized as we get to the weeks just before a release. We can release a new version of Kubernetes once they are empty. We will have two milestones per minor release.
+- **priority/P1**: Must be staffed and worked on either currently, or very soon,
+ideally in time for the next release.
+
+- **priority/P2**: There appears to be general agreement that this would be good
+to have, but we may not have anyone available to work on it right now or in the
+immediate future. Community contributions would be most welcome in the mean time
+(although it might take a while to get them reviewed if reviewers are fully
+occupied with higher priority issues, for example immediately before a release).
+
+- **priority/P3**: Possibly useful, but not yet enough support to actually get
+it done. These are mostly place-holders for potentially good ideas, so that they
+don't get completely forgotten, and can be referenced/deduped every time they
+come up.
+
+### Milestones
+
+We additionally use milestones, based on minor version, for determining if a bug
+should be fixed for the next release. These milestones will be especially
+scrutinized as we get to the weeks just before a release. We can release a new
+version of Kubernetes once they are empty. We will have two milestones per minor
+release.
 
 - **vX.Y**: The list of bugs that will be merged for that milestone once ready.
-- **vX.Y-candidate**: The list of bug that we might merge for that milestone.  A bug shouldn't be in this milestone for moe than a day or two towards the end of a milestone.  It should be triaged either into vX.Y, or moved out of the release milestones.
 
-The above priority scheme still applies, so P0 and P1 bugs are work we feel must get done before release, while P2 and P3 represent work we would merge into the release if it gets done, but we wouldn't block the release on it. A few days before release, we will probably move all P2 and P3 bugs out of that milestone tag in bulk.
+- **vX.Y-candidate**: The list of bug that we might merge for that milestone. A
+bug shouldn't be in this milestone for more than a day or two towards the end of
+a milestone. It should be triaged either into vX.Y, or moved out of the release
+milestones.
+
+The above priority scheme still applies. P0 and P1 issues are work we feel must
+get done before release.  P2 and P3 issues are work we would merge into the
+release if it gets done, but we wouldn't block the release on it. A few days
+before release, we will probably move all P2 and P3 bugs out of that milestone
+in bulk.
 
 <!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
 [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/devel/issues.md?pixel)]()

docs/devel/logging.md

@@ -31,13 +31,17 @@ Documentation for other releases can be found at
 <!-- END STRIP_FOR_RELEASE -->
 
 <!-- END MUNGE: UNVERSIONED_WARNING -->
-Logging Conventions
-===================
 
-The following conventions for the glog levels to use.  [glog](http://godoc.org/github.com/golang/glog) is globally preferred to [log](http://golang.org/pkg/log/) for better runtime control.
+## Logging Conventions
+
+The following conventions for the glog levels to use.
+[glog](http://godoc.org/github.com/golang/glog) is globally preferred to
+[log](http://golang.org/pkg/log/) for better runtime control.
 
 * glog.Errorf() - Always an error
+
 * glog.Warningf() - Something unexpected, but probably not an error
+
 * glog.Infof() has multiple levels:
   * glog.V(0) - Generally useful for this to ALWAYS be visible to an operator
     * Programmer errors
@@ -56,7 +60,9 @@ The following conventions for the glog levels to use.  [glog](http://godoc.org/g
   * glog.V(4) - Debug level verbosity (for now)
     * Logging in particularly thorny parts of code where you may want to come back later and check it
 
-As per the comments, the practical default level is V(2).  Developers and QE environments may wish to run at V(3) or V(4). If you wish to change the log level, you can pass in `-v=X` where X is the desired maximum level to log.
+As per the comments, the practical default level is V(2). Developers and QE
+environments may wish to run at V(3) or V(4). If you wish to change the log
+level, you can pass in `-v=X` where X is the desired maximum level to log.
 
 
 <!-- BEGIN MUNGE: GENERATED_ANALYTICS -->

docs/devel/making-release-notes.md

@@ -38,10 +38,14 @@ This documents the process for making release notes for a release.
 
 ### 1) Note the PR number of the previous release
 
-Find the most-recent PR that was merged with the previous .0 release.  Remember this as $LASTPR.
-_TODO_: Figure out a way to record this somewhere to save the next release engineer time.
+Find the most-recent PR that was merged with the previous .0 release. Remember
+this as $LASTPR.
 
-Find the most-recent PR that was merged with the current .0 release.  Remember this as $CURRENTPR.
+- _TODO_: Figure out a way to record this somewhere to save the next
+release engineer time.
+
+Find the most-recent PR that was merged with the current .0 release. Remember
+this as $CURRENTPR.
 
 ### 2) Run the release-notes tool
 
@@ -52,7 +56,7 @@ ${KUBERNETES_ROOT}/build/make-release-notes.sh $LASTPR $CURRENTPR
 ### 3) Trim the release notes
 
 This generates a list of the entire set of PRs merged since the last minor
-release.  It is likely long and many PRs aren't worth mentioning.  If any of the
+release. It is likely long and many PRs aren't worth mentioning. If any of the
 PRs were cherrypicked into patches on the last minor release, you should exclude
 them from the current release's notes.
 
@@ -67,9 +71,13 @@ With the final markdown all set, cut and paste it to the top of `CHANGELOG.md`
 
 ### 5) Update the Release page
 
-   * Switch to the [releases](https://github.com/kubernetes/kubernetes/releases) page.
+   * Switch to the [releases](https://github.com/kubernetes/kubernetes/releases)
+page.
+
    * Open up the release you are working on.
+
    * Cut and paste the final markdown from above into the release notes
+
    * Press Save.