merge conflict'

01.1-whyopen.md

@@ -0,0 +1,17 @@
+# Why Open?
+
+Before defining the **how** of working open, it's worth spending some time thinking about why you would want to.
+
+Working open is **not** a way to get free engineering or other labour for your project, although you can find efficiencies you wouldn't have found otherwise when you help people solve their own problems.
+
+Working open is **not** a way to hit your deadline faster, and in fact you should be prepared for the reality that having a community around your project will require intention and mindfullness on your part.
+
+Working open is **not** a way to avoid process or structure, and done properly should make power structures transparent and participatory.
+
+It **is** a way to introduce new perspectives, incorporate user-centric thinking, and allow your project to achieve it's highest impact.
+
+It can sharpen your thinking and find errors you hadn't known you'd made.  This is expressed in the "many eyes" principle or [https://en.wikipedia.org/wiki/Linus's_Law Linus's Law]:  "given enough eyeballs, all bugs are shallow". In other words, the more people involved, the more likely someone is to spot an error.
+
+Increasing the amount of contributors can also increase the diversity of your project and make sure that it serves a wide constituency.  In the words of Aspiration technology's Allen Gunn:
+
+>"I believe in the “many eyes” principle — but also in the **“many hearts and souls”** principle. Having many personalities, values and experience-sets involved in creating something intrinsically makes the finished product more robust and broadly relevant — versus, say, three privileged white guys in Silicon Valley kicking something out."

01.2-working_open.md

@@ -0,0 +1,58 @@
+# Working Open
+
+Working Open is a means to an end.   It should enable **useful participation**. Rather than a flood of comments from the peanut gallery, working open helps us be more agile, produces visible progress and momentum, and importantly, helps you maximize the amount of good you can do in the world with small resources (from "[How To Work Open](http://openmatt.org/2011/04/06/how-to-work-open/)" by Matt Thompson).
+
+
+Working open requires structuring efforts so that "outsiders" can meaningfully participate, and become "insiders" as appropriate (from [Working Open, Mozilla Wiki](https://wiki.mozilla.org/Working_open).  Practically, this means a mixture of tooling, process, and social norms. 
+
+# Tooling
+
+In his (highly recommended) book "[Producing Open Source Software](http://producingoss.com/)", Karl Vogel outlined some tools that every open source project needs:
+
+>**Web site**
+Primarily a centralized, one-way conduit of information from the project out to the public. The web site may also serve as an administrative interface for other project tools.
+
+The website for [Node.js](https://nodejs.org/) is an example of a project website that points to it's other modes of communication, and points prospective developers and contributors to a place to download the source code immediately
+
+
+>**Mailing lists / Message forums**
+Usually the most active communications forum in the project, and the "medium of record."
+
+Mozilla has [hundreds of mailing lists](https://lists.mozilla.org/listinfo) for various software projects and activities.  They are all archived using Google Groups - for an example, see the [accessibility](https://groups.google.com/forum/#!forum/mozilla.accessibility) mailing list 
+
+>**Version control**
+Enables developers to manage code changes conveniently, including reverting and "change porting". Enables everyone to watch what's happening to the code.
+
+Git has become a very popular option for version control, and GitHub for hosting the version control system.  
+
+
+>**Bug tracking**
+Enables developers to keep track of what they're working on, coordinate with each other, and plan releases. Enables everyone to query the status of bugs and record information (e.g., reproduction recipes) about particular bugs. Can be used for tracking not only bugs, but also tasks, releases, new features, etc.
+
+Increasingly bug tracking and version control take place on the same platform.  You can see the open issues for the Django Project on their [code page](https://code.djangoproject.com/query), or those of [Mozilla's Thimble Editor](https://thimble.webmaker.org/), where [issues are tracked directly on GitHub](https://github.com/mozilla/thimble.webmaker.org/issues).
+
+>**Real-time chat**
+A place for quick, lightweight discussions and question/answer exchanges. Not always archived completely.
+
+Mozilla has used IRC extensively, and maintains a server that anyone can join.  This is often the quickest way to meet a real human on the project.  A popular alternative is [Slack](https://slack.com/).
+
+#Process
+The decision making process of open source projects needs to be carefully considered.  If potential contributors are concerned that decisions will be made unilaterally, they may be hesitant to invest their time.  Karl Fogel is again helpful here when encouraging hosts of open source projects to:
+
+>**Avoid Private Discussions**
+As slow and cumbersome as public discussion can be, it's almost always preferable in the long run. Making important decisions in private is like spraying contributor repellant on your project. No serious contributor would stick around for long in an environment where a secret council makes all the big decisions. Furthermore, public discussion has beneficial side effects that will last beyond whatever ephemeral technical question was at issue:
+
+>The discussion will help train and educate new developers. You never know how many eyes are watching the conversation; even if most people don't participate, many may be lurking silently, gleaning information about the software.
+
+>The discussion will train you in the art of explaining technical issues to people who are not as familiar with the software as you are. This is a skill that requires practice, and you can't get that practice by talking to people who already know what you know.
+
+>The discussion and its conclusions will be available in public archives forever after, enabling future discussions to avoid retracing the same steps.
+
+#Social Norms
+It is important to make explicit that yours is a welcoming community.  For example, the Mozilla Community Participation Guidelines state:
+
+> The Mozilla Project welcomes and encourages participation by everyone. It doesn’t matter how you identify yourself or how others perceive you: we welcome you. We welcome contributions from everyone as long as they interact constructively with our community, including, but not limited to people of varied age, culture, ethnicity, gender, gender-identity, language, race, sexual orientation, geographical location and religious views.
+
+These types of document are often described as "codes of conduct".  Another example is from the [SASS framework](http://sass-lang.com/community-guidelines).
+
+Many software projects embed these codes of content within their codebase, so that they can be forked and added to in ways that create a "living document".  An example of this can be found [within the Angular project](https://github.com/angular/code-of-conduct/blob/master/CODE_OF_CONDUCT.md)

01.3-contributors.md

@@ -0,0 +1,7 @@
+# Who are Contributors?
+
+A contributor is anyone who has given time, expertise or talent to support your
+project. Contributions can be in the form of code, testing, issue creation, discussion,
+suggestions and more.
+
+* https://wiki.mozilla.org/Community

01.4-openatmozilla.md

@@ -0,0 +1,17 @@
+# Open at Mozilla
+
+Mozilla is one of the world's largest Open Source project, and our commitment to openness is reflected in the 2nd point of our [manifesto](https://www.mozilla.org/en-US/about/manifesto/):
+
+>The Internet is a global public resource that must remain open and accessible.
+
+To achieve this goal, Mozilla produces the [Firefox web browser](https://www.mozilla.org/firefox/), which is built by both paid staff and thousands of contributors around the world.  Contributors participate in a myriad of ways to build the browser - from submitting code, to translating, to writing support documentation, to running tests - it is the [product of many hands](https://www.mozilla.org/en-US/contribute/).
+
+Mozilla also has a deep commitment to [Web Literacy](https://teach.mozilla.org/teach-like-mozilla/web-literacy/) - the notion that all citizens should be able to read, write and participate on the web.  To achieve this goal, The Mozilla Learning Network offers [programs and a global community](https://teach.mozilla.org/) dedicated to helping people learn the most important skills of our age.
+
+Mozilla has many other activities - from our work in [advocating for Internet policy](https://advocacy.mozilla.org/), to placing fellows in the [Science](https://www.mozillascience.org/), [Journalism](https://opennews.org/) and [Advocacy](https://advocacy.mozilla.org/open-web-fellows/) communities.
+
+All of these efforts include the work of contributors - some paid, some volunteer.  Mozilla holds many [public community calls](https://wiki.mozilla.org/WeeklyUpdates) where contributors can keep track of the day to decisions and progress of the Mozilla Project.  All of the engineering on Firefox takes place within the [Bugzilla](https://bugzilla.mozilla.org/) public issue tracker, and the activities of the [Mozilla Foundation](http://build.webmaker.org/) are also tracked publicly and are available for you to see.
+
+We operate under an open governance [module ownership](https://www.mozilla.org/en-US/about/governance/policies/module-ownership/ ) system.
+
+The [opportunities for contribution](https://www.mozilla.org/en-US/contribute/) at Mozilla are vast, and Mozilla would not be able to operate without these contributions.

README.md

@@ -28,9 +28,9 @@ Are we missing anything? Have a comment? [Let us know what you think](https://gi
 
 ## Table of Contents
 
-* [Mozilla 101](http://mozillascience.github.io/leadership-training/01-mozilla_101.html)
-  * [Working Open](http://mozillascience.github.io/leadership-training/01.1-working_open.html)
-  * [Who are Contributors?](http://mozillascience.github.io/leadership-training/01.2-contributors.html)
+* [Why Open?](01.1-whyopen.html)
+  * [Working Open Basics](01.2-working_open.html)
+  * [Open at Mozilla](01.4-openatmozilla.html)
 * [Project Setup](http://mozillascience.github.io/leadership-training/02-setup.html)
   * [Lowering Barriers](http://mozillascience.github.io/leadership-training/02.1-newcomers.html)
   * [Roadmapping](http://mozillascience.github.io/leadership-training/02.2-roadmap.html)
@@ -49,9 +49,10 @@ Are we missing anything? Have a comment? [Let us know what you think](https://gi
 * [Further Reading](http://mozillascience.github.io/leadership-training/06-reading.html)
 * [Edit this Book](http://mozillascience.github.io/leadership-training/CONTRIBUTING.html)
 
+## TODO: Who is this for?
 
-
-### License
+## License
 ![Creative Commons License](https://i.creativecommons.org/l/by/4.0/88x31.png)
 
 This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/).
+

SUMMARY.md

@@ -1,8 +1,8 @@
 This is the TOC on the sidebar.  Probably shows up in a PDF version too.
 
-* [Mozilla 101](01-mozilla_101.md)
-  * [Working Open](01.1-working_open.md)
-  * [Who are Contributors?](01.2-contributors.md)
+* [Why Open?](01.1-whyopen.md)		
+  * [Working Open Basics](01.2-working_open.md)
+  * [Open at Mozilla](01.4-openatmozilla.md)	
 * [Project Setup](02-setup.md)
   * [Lowering Barriers](02.1-newcomers.md)
   * [Roadmapping](02.2-roadmap.md)