Add content model

docs/content-model.md

@@ -0,0 +1,128 @@
+# Content Model
+
+The Open Source Handbook helps individuals, communities, and companies embrace open source software. It explains not only how to accomplish a task, but why you’d want to, and how that task fits into the larger story of consuming, contributing to, and producing open source software.
+
+This content is created and curated by GitHub, and covers topics that are very relevant to GitHub users, but it is not specific to GitHub products.
+
+For content that is specific to GitHub products, see:
+
+- help.github.com - gets existing users unstuck and back to work.
+- guides.github.com -  tutorials about a larger idea or product feature for new users.
+
+## Dimensions & Topics
+
+Each piece of content is grouped under a *dimension* and *topic*.
+
+A *dimension* roughly describes an individual’s relationship with an open source project:
+
+0. **Basics**: rudimentary introduction to the concepts of open source.
+0. (coming in v2) **Consuming**: using open source software.
+0. (coming in v2) **Contributing**: getting involved and improving existing open source projects.
+0: **Producing**: starting, growing, and maintaining your own open source project.
+
+A “topic” groups together content around a high-level goal of the user, and should begin with a [gerund](https://en.wikipedia.org/wiki/Gerund).
+
+Examples:
+
+- :smile: “Building a community”
+- :smile: “Reviewing contributions”
+- :smile: “Choosing a license”
+- :cry: “Code review”
+- :cry: “Legal”
+
+## Common Elements
+
+Every piece of content contains these elements:
+
+- [Introduction](#introductions)
+
+Each piece of content may also include:
+
+- [References](#references)
+- [Credits](#credits) - 
+
+### Introductions
+
+Each piece of content should contain an *introduction*, which is similar to a thesis statement. These allow the reader to decide if they should continue reading or move on to find the information they were actually looking for. Introductions should explain the basic point of the content *without actually referencing the content itself*. For example:
+
+- :smile: "Pull requests are a lightweight way to work on actual files collaboratively without introducing errors to production."
+- :cry: "This article should introduce you to the benefits pull requests can introduce to your workflow on GitHub."
+
+Introductions are a delicate balance between showing and telling. Don't *tell* the user what they should learn, let the fact that they learned a new thing be implied.
+
+### References
+
+We never want to leave a user at a dead end, especially in situations where we leave out nuance in pursuit of accessibility. Every piece of content should link to any related information. If another good resource exists on the internet, link to it. Some examples include:
+
+- Related content in the handbook
+- GitHub Help content for more details on _how_ to do something.
+- Projects on GitHub that illustrate the introduced concepts.
+- External blog posts, articles, or resources
+
+### Credits
+
+In the spirit of open source, this handbook aims to reuse good content that already exists and is licensed for reuse, even if it requires heavy editing to match the structure and style of the handbook.
+
+Each piece of content should include attribution for any content that it was inspired by or derived from. The content must be published with an explicit license that allows reuse for commercial purposes (CC0, CC-BY, CC-BY-SA are all acceptable).
+
+## Content Types
+
+The handbook contains a few types of content:
+
+- [Conceptual](#conceptual-content)
+- [Tactical](#tactical-content)
+- [Referential](#referential-content)
+- [Frequently Asked Questions (FAQs)](#frequently-asked-questions-faqs)
+
+### Conceptual Content
+
+Conceptual content answers the questions "What is this?" and "Why do I care?"  Open source introduces lots of unique, innovative concepts to people with varying levels of experience and various disciplines.
+
+Conceptual content should either be generalized for *all* audiences, or tailored to one audience, but should not attempt to do both. Content generalized to all audiences could also reference [related content](#related-content) that is specific to an individual audience. This requires some thinking! For example, a high-level introduction to open source can be generalized for all audiences, but there are unique implications for developers, companies, and non-technical that warrant separate pieces of content for each audience.
+
+Conceptual content is structured as:
+
+- **Title** - TODO: advice on titles
+- **[Introduction](#introductions)**
+- ???
+
+### Tactical Content
+
+Tactical content answers the question "How?". This is arguably the most common type of content developed for the handbook because it is meant to describe best practices in open source. This content should explain the steps necessary to achieve a single goal. If there is not a community best practice, it should give an overview of a few approaches and reference other tactical content for details.
+
+Tactical content is structured as:
+
+- **Title** - Tactical articles should begin with a gerund. For example, "Enforcing a code of conduct”.
+
+- **Introduction** - The introduction should should explain what the user will specifically accomplish by applying these tactics, and can and probably should reference [conceptual content](#conceptual-content) to further explain why you would want to apply the tactics. For example, an article on “Enforcing a Code of Conduct” should reference the conceptual content “About codes of conduct”.
+
+- **Tactical sections** - These sections explain each tactic involved in achieving the goal. They may be procedural steps, or just a list of individual tactics that should be considered. For example, an article on “Enforcing a code of conduct” might have a tactical section called “Responding to reports of abuse”.
+
+- **Summarizing conclusion** - Conclude by briefly reviewing how these tactics connect to the larger story and encouraging the user to find ways to apply them to their situation.
+
+- Links to **Related content** - Hopefully the user is excited about what they've just learned and wants to find out more.
+
+### Frequently Asked Questions (FAQs)
+
+FAQ articles aim to directly address common questions or misconceptions. These tend to be questions that have known but nuanced answers, such as “Is open source software secure?” or “How do I convince my boss to let me contribute to open source?”.
+
+FAQ content is structured as:
+
+- **Title** should be in the form of a question. The question should be succinct and as close to the most widely asked form of the question, because not every person will ask a question in the same way. For example, “What is open source?”, or “How do I make money writing open source software?”
+
+- **Body** should be as brief as possible - answering the question and linking off to more information where appropriate. Ask yourself if the question (the title) could be rephrased to create [conceptual](#conceptual-content) or [tactical](#tactical-content) content.
+
+### Referential Content
+
+Referential content answers the question "What are the pieces?" Reference material often contains a certain amount of conceptual material, but the best reason for presenting referential content separately from conceptual content is reuse.
+
+Referential articles should *not* contain procedural content in the form of steps, but can link off to such material.
+
+Referential content is structured as:
+
+
+- **Title** - should begin with a noun describing the information that's being referenced, followed by how you'd use that thing. For example, "Countries that support SMS for two-factor authentication".
+
+It's always a good idea to link a referential article to a tactical or conceptual article, even if that's in the **Further reading** section at the end of the article.
+
+