Miroirs/devdocs
1
0
Fork 0
mirror of https://github.com/freeCodeCamp/devdocs synced 2024-11-16 19:48:10 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Tweak README.md and CONTRIBUTING.md

Browse source
This commit is contained in:
Thibaut 2014-04-19 12:28:24 -04:00
parent bcd4a5b522
commit 2ace9f2f18
2 changed files with 13 additions and 13 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
CONTRIBUTING.md
View file

@ -48,14 +48,14 @@ Use the [Trello board](https://trello.com/b/6BmTulfx/devdocs-documentation) wher
See the [wiki](https://github.com/Thibaut/devdocs/wiki) to learn how to add new documentations.
**Important:** in order to keep things fast and manageable, only the documentation of popular open source projects will be accepted into DevDocs. As more projects find their way in, the required level of popularity will gradually decrease. Additionally, the documentation's license must permit alteration, redistribution, and commercial use of the work. Software vendors that wish to add commercial software documentation to DevDocs may contact me privately.
**Important:** the documentation's license must permit alteration, redistribution, and commercial use of the work. Software vendors that wish to add commercial software documentation to DevDocs may contact me privately.
**Please open an issue before adding any new documentation.**
**Please open an issue before adding a new documentation.**
In addition to the [guidelines for contributing code](#contributing-code-and-features), the following guidelines apply to pull requests that add a new documentation:
* Your documentation must come with a clean and official icon, in both 1x and 2x resolutions (16x16 and 32x32 pixels). This is important because icons are the only thing differentiating search results in the UI. If a project doesn't have an official icon, it won't be accepted into DevDocs. Sorry.
* DevDocs favors quality over quantity. Your documentation should only include API/reference documents that most developers may wish to read semi-regularly. By reducing the number of entries we make it easier to find other, more relevant entries. _(Note: you are more than welcome to submit pull requests removing seldom-used entries from existing documentations.)_
* Your documentation must come with an official icon, in both 1x and 2x resolutions (16x16 and 32x32 pixels). This is important because icons are the only thing differentiating search results in the UI. If a project doesn't have an official icon, it won't be accepted into DevDocs, sorry.
* DevDocs favors quality over quantity. Your documentation should only include API/reference documents that most developers may wish to read semi-regularly. By reducing the number of entries we make it easier to find other, more relevant entries. _(Note: you're more than welcome to submit pull requests removing seldom-used entries from existing documentations.)_
* Try to remove as much content and HTML markup as possible, particularly content which isn't associated with any entries (e.g. introduction, changelog, etc.).
* Names must be as short as possible and unique across the documentation.
* The number of types (categories) should ideally be less than 100.
@ -63,15 +63,15 @@ In addition to the [guidelines for contributing code](#contributing-code-and-fea
## Updating existing documentations
Please don't submit a pull request updating the version number of a documentation unless you have verified that it can be generated properly using the current code. Because the original content will have changed, the code will likely need to be tweaked.
Please don't submit a pull request updating the version number of a documentation unless you've verified that it can be generated properly using the current code. Because the original content will have changed, the code will likely need to be tweaked.
To ask that an existing documentation be updated, please use the [Trello board](https://trello.com/b/6BmTulfx/devdocs-documentation) or the [mailing list](https://groups.google.com/d/forum/devdocs).
To ask that an existing documentation be updated, please use the [Trello board](https://trello.com/c/2B0hmW7M/52-request-updates-here) or the [mailing list](https://groups.google.com/d/forum/devdocs).
## Other contributions
Besides new docs and features, here are other ways you can contribute:
* **Improve words and sentences.** English isn't my first language so if you notice grammatical or usage errors, feel free to submit a pull request — it'll be much appreciated. (Note: American English is the preferred form)
* **Improve words and sentences.** English isn't my first language so if you notice grammatical or usage errors, feel free to submit a pull request — it'll be much appreciated.
* **Participate in the issue tracker.** Your opinion matters — feel free to add comments to existing issues. You're also welcome to participate to the [mailing list](https://groups.google.com/d/forum/devdocs).
## Coding conventions

12
README.md
View file

@ -19,7 +19,7 @@ DevDocs is free and open source. If you like it, please consider funding the pro
Unless you wish to use DevDocs offline or contribute to the code, I recommend using the hosted version at [devdocs.io](http://devdocs.io). It's up-to-date and requires no setup.
DevDocs is made of two separate pieces: a Ruby scraper responsible for generating the documentation files and indexes, and a JavaScript front-end powered by a small Sinatra app.
DevDocs is made of two separate pieces: a Ruby scraper responsible for generating the documentation and index files, and a JavaScript front-end powered by a small Sinatra app.
DevDocs requires Ruby 2.1 and a JavaScript runtime supported by [ExecJS](https://github.com/sstephenson/execjs#readme) (included in OS X and Windows; [Node.js](http://nodejs.org/) on Linux). Once you have these installed, run the following commands:
@ -40,9 +40,9 @@ The `thor docs:download` command is used to download/update individual documenta
DevDocs aims to make reading and searching reference documentation fast, easy and enjoyable.
The app's main goals are to: keep booting and loading times as short as possible; improve the quality, speed, and order of search results; maximize the use of caching and other performance optimizations; maintain a clean, readable user interface; support full keyboard navigation; reduce “context switch” by using a consistent typography and design across all documentations; reduce clutter by focusing on a specific category of content (API/reference) and by indexing only the minimum useful to most developers.
The app's main goals are to: keep boot and load times as short as possible; improve the quality, speed, and order of search results; maximize the use of caching and other performance optimizations; maintain a clean, readable user interface; support full keyboard navigation; reduce “context switch” by using a consistent typography and design across all documentations; reduce clutter by focusing on a specific category of content (API/reference) and by indexing only the minimum useful to most developers.
**Note:** DevDocs is neither a programming guide nor a search engine. All content is pulled from third-party sources and the project doesn't intend to compete with full-text search engines. Its backbone is metadata: each piece of content must be identified by a unique, obvious and short string. Thus, tutorials, guides and other content that don't fit this requirement are outside the scope of the project.
**Note:** DevDocs is neither a programming guide nor a search engine. All content is pulled from third-party sources and the project doesn't intend to compete with full-text search engines. Its backbone is metadata: each piece of content must be identified by a unique, obvious and short string. Tutorials, guides and other content that don't fit this requirement are outside the scope of the project.
## App
@ -50,7 +50,7 @@ The web app is all JavaScript, written in [CoffeeScript](http://coffeescript.org
Many of the code's design decisions were driven by the fact that the app uses XHR to load content directly into the main frame. This includes stripping the original documents of most of their HTML markup (e.g. scripts and stylesheets) to avoid polluting the main frame, and prefixing all CSS class names with an underscore to prevent conflicts.
Another driving factor is performance and the fact that everything happens in the browser. `applicationCache` (which comes with its own set of constraints) and `localStorage` are used to speed up the boot time while memory consumption is kept in check by allowing the user to pick his/her own set of documentations. On the other hand, the search algorithm is currently not very sophisticated because it needs to be fast even searching through 100k entries.
Another driving factor is performance and the fact that everything happens in the browser. `applicationCache` (which comes with its own set of constraints) and `localStorage` are used to speed up the boot time, while memory consumption is kept in check by allowing the user to pick his/her own set of documentations. On the other hand, the search algorithm is currently not very sophisticated because it needs to be fast even searching through 100k entries.
DevDocs being a developer tool, the browser requirements are high:
@ -71,7 +71,7 @@ This allows the code to take advantage of the latest DOM and HTML5 APIs and make
The scraper is responsible for generating the documentation and index files (metadata) used by the [app](#app). It's written in Ruby under the `Docs` module.
There are currently two kinds of scrapers: `UrlScraper` which downloads files via HTTP and `FileScraper` which reads them from the local filesystem. They both make copies of HTML documents, recursively following links that match a given set of rules and applying all sorts of modifications along the way, in addition to building an index of the files and their metadata. Documents are parsed using [Nokogiri](http://nokogiri.org).
There are currently two kinds of scrapers: `UrlScraper` which downloads files via HTTP and `FileScraper` which reads them from the local filesystem. They both make copies of HTML documents, recursively following links that match a set of rules and applying all sorts of modifications along the way, in addition to building an index of the files and their metadata. Documents are parsed using [Nokogiri](http://nokogiri.org).
Modifications made to each document include:
* removing content such as the document structure (`<html>`, `<head>`, etc.), comments, empty nodes, etc.
@ -80,7 +80,7 @@ Modifications made to each document include:
* replacing all internal (scraped) URLs with their unqualified and relative counterpart
* adding content, such as a title and link to the original document
These modifications are applied through a set of filters using the [HTML::Pipeline](https://github.com/jch/html-pipeline) library. Each scraper includes filters specific to its documentation, one of which is tasked with figuring out the pages' metadata.
These modifications are applied via a set of filters using the [HTML::Pipeline](https://github.com/jch/html-pipeline) library. Each scraper includes filters specific to its documentation, one of which is tasked with figuring out the pages' metadata.
The end result is a set of normalized HTML partials and a JSON index file. Because the index files are loaded separately by the [app](#app) following the user's preferences, the code also creates a JSON manifest file containing information about the documentations currently available on the system (such as their name, version, update date, etc.).