trailing punctuation in header

Signed-off-by: yupeng <yu.peng36@zte.com.cn>

MAINTAINERS_GUIDE.md

@@ -7,7 +7,7 @@ features to the project. But most of your time will be spent reviewing,
 cleaning up, documenting, answering questions, justifying design
 decisions - while everyone has all the fun! But remember - the quality
 of the maintainers work is what distinguishes the good projects from the
-great.  So please be proud of your work, even the unglamourous parts,
+great.  So please be proud of your work, even the unglamorous parts,
 and encourage a culture of appreciation and respect for *every* aspect
 of improving the project - not just the hot new features.
 
@@ -18,7 +18,7 @@ available to them.
 This is a living document - if you see something out of date or missing,
 speak up!
 
-## What are a maintainer's responsibility?
+## Maintainer's responsibility
 
 It is every maintainer's responsibility to:
 
@@ -29,7 +29,7 @@ It is every maintainer's responsibility to:
 * 4) Make sure their component respects the philosophy, design and
   roadmap of the project.
 
-## How are decisions made?
+## The method of making decisions
 
 Short answer: with pull requests to the runc repository.
 
@@ -51,58 +51,58 @@ All decisions affecting runc, big and small, follow the same 3 steps:
 * Step 2: Discuss the pull request. Anyone can do this.
 
 * Step 3: Accept (`LGTM`) or refuse a pull request. The relevant maintainers do 
-this (see below "Who decides what?")
+this (see below "Someone who makes decisions")
 
-### I'm a maintainer, should I make pull requests too?
+*I'm a maintainer, should I make pull requests too?*
 
 Yes. Nobody should ever push to master directly. All changes should be
 made through a pull request.
 
-## Who decides what?
+## Someone who makes decisions
 
 All decisions are pull requests, and the relevant maintainers make
 decisions by accepting or refusing the pull request. Review and acceptance
-by anyone is denoted by adding a comment in the pull request: `LGTM`. 
+by anyone is denoted by adding a comment in the pull request: `LGTM`.
 However, only currently listed `MAINTAINERS` are counted towards the required
 two LGTMs.
 
 Overall the maintainer system works because of mutual respect across the
 maintainers of the project.  The maintainers trust one another to make decisions
-in the best interests of the project.  Sometimes maintainers can disagree and 
+in the best interests of the project.  Sometimes maintainers can disagree and
 this is part of a healthy project to represent the point of views of various people.
-In the case where maintainers cannot find agreement on a specific change the 
-role of a Chief Maintainer comes into play.  
+In the case where maintainers cannot find agreement on a specific change the
+role of a Chief Maintainer comes into play.
 
-The Chief Maintainer for the project is responsible for overall architecture 
-of the project to maintain conceptual integrity.  Large decisions and 
-architecture changes should be reviewed by the chief maintainer.  
-The current chief maintainer for the project is Michael Crosby (@crosbymichael).  
+The Chief Maintainer for the project is responsible for overall architecture
+of the project to maintain conceptual integrity.  Large decisions and
+architecture changes should be reviewed by the chief maintainer.
+The current chief maintainer for the project is Michael Crosby (@crosbymichael).
 
 Even though the maintainer system is built on trust, if there is a conflict
-with the chief maintainer on a decision, their decision can be challenged 
-and brought to the technical oversight board if two-thirds of the 
-maintainers vote for an appeal. It is expected that this would be a 
+with the chief maintainer on a decision, their decision can be challenged
+and brought to the technical oversight board if two-thirds of the
+maintainers vote for an appeal. It is expected that this would be a
 very exceptional event.
 
 
-### How are maintainers added?
+### The method of adding maintainers
 
 The best maintainers have a vested interest in the project.  Maintainers
 are first and foremost contributors that have shown they are committed to
-the long term success of the project.  Contributors wanting to become 
-maintainers are expected to be deeply involved in contributing code, 
+the long term success of the project.  Contributors wanting to become
+maintainers are expected to be deeply involved in contributing code,
 pull request review, and triage of issues in the project for more than two months.
 
-Just contributing does not make you a maintainer, it is about building trust 
+Just contributing does not make you a maintainer, it is about building trust
 with the current maintainers of the project and being a person that they can
 depend on and trust to make decisions in the best interest of the project.  The
 final vote to add a new maintainer should be approved by over 66% of the current
-maintainers with the chief maintainer having veto power.  In case of a veto, 
+maintainers with the chief maintainer having veto power.  In case of a veto,
 conflict resolution rules expressed above apply.  The voting period is
 five business days on the Pull Request to add the new maintainer.
 
 
-### What is expected of maintainers?
+### The expectations for maintainers
 
 Part of a healthy project is to have active maintainers to support the community
 in contributions and perform tasks to keep the project running.  Maintainers are

libcontainer/SPEC.md

@@ -306,7 +306,7 @@ a container.
 | Exec           | Execute a new process inside of the container  ( requires setns )  |
 | Set            | Setup configs of the container after it's created                  |
 
-### Execute a new process inside of a running container.
+### Execute a new process inside of a running container
 
 User can execute a new process inside of a running container. Any binaries to be
 executed must be accessible within the container's rootfs.