edit: tighten up language in two sections

* Focusing on: word usage, sentence structure, and flow in longer sentences.
* Removed a few words that were mostly redundant.

maintain/bdfl.md

@@ -3,19 +3,19 @@
 The **Benevolent Dictator For Life** is a term for an Open Source project
 leadership model that is commonly used, where the individual who created the
 project remains the leader and ultimately has the final say and veto on
-decisions. Oftentimes this power is only implied and silent, not actually
+decisions. Oftentimes this power is only implied, not actually
 written down or pronounced anywhere.
 
-Like with any dictatorship, it is an effective and speedy model as in it can
-avoid long and tiresome debates or voting procedures with a single person's
-view and guidance to keep the course straight. If the dictator takes the wrong
-turn however, or makes their decrees against what you think is the right way,
-the model breaks fairly quickly.
+Like with any dictatorship, it is an effective and speedy model that can
+avoid long and tiresome debates or voting procedures because there is a single person's
+guidance to keep the course straight. If the dictator takes the wrong
+turn however, or makes their decrees against what the community thinks is the right way,
+the model breaks down fairly quickly.
 
 I have worked in several projects with benevolent dictators and I am myself a
 BDFL some places. In my view, that is not an ideal way to run a project by any
-means. Not even if you are the BDFL. It is hard to know where to go and what
-decisions to make. As a BDFL, I have always made a serious effort to listen in
-what people say, what they want and where the world seems to suggest is a
+means, even if you are the BDFL. It is hard to know where to go and what
+decisions to make. As a BDFL, I have always made a serious effort to listen to
+what people say, what they want, and where the world seems to suggest is a
 suitable place for the project to set its next tent pole.
 

maintain/security.md

@@ -4,17 +4,17 @@ Taking care of security issues can be a significant undertaking. See
 [security](../security.md).
 
 In my daily Open Source work, I find that when someone reports a suspected
-security problem, assessing the possibility, risk and impact of the issue can
-take a significant effort and time.
+security problem, assessing the possible risk and impact of the issue can
+take significant effort and time.
 
-Is it a security problem? If it is a security problem, what is the impact, the
-severity and how should it be fixed?
+Is it a security problem? If it is a security problem, what is the severity 
+and how should it be fixed?
 
 Security problems should be addressed as quickly as possible to reduce the
-risk of harm to existing users out there that run the vulnerable versions. It
+risk of harm to existing users who are using vulnerable versions. It
 is also important that the knowledge of a security problem and the work on the
 fix are done behind closed doors. When the fix is written, reviewed, tested
-and verified you can announce the vulnerability and the associated fix to the
-world. The idea of course being to minimize the impact for vulnerable users
-and give them a change to upgrade to a fixed version once the bad guys out
-there also get told about the flaw and therefore can start to exploit it.
+and verified, you can announce the vulnerability and the associated fix to the
+world. The idea of course is to minimize the impact for vulnerable users
+by giving them a chance to upgrade to a fixed version as soon as the bad guys 
+hear about the flaw and therefore can start to exploit it.