-
Notifications
You must be signed in to change notification settings - Fork 1
/
README
179 lines (122 loc) · 4.29 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
#######
Docness
#######
Vision, tips and conventions about documentation content and workflows.
**********
Ressources
**********
* online documentation: http://docness.readthedocs.org/
* code repository: https://github.com/benoitbryon/docness
* bugtracker: https://github.com/benoitbryon/docness/issues
******
Status
******
**This is a proposal.**
Although applied on private or small projects, this documentation howto should
be considered as a proposal. It is not industry standard and have not been
supported by some "big" projects.
However, **give it a try!** and `give feedback`_.
******
Vision
******
Context
=======
In software development, when developers contribute to projects, they read and
write documentation. Most people agree documentation matters.
But everybody has its own culture, habits and vision about documentation.
Thus it appears quite difficult to share vision about documentation and
then create efficient documentation.
Goal
====
.. code-block:: gherkin
Feature: shared vision and best practices about documentation
In order to share vision about documentation and create efficient
documentation material
As member of a development team
I want to share best practices about documentation.
Scenario: Adopt documentation-related vision and practices
Given a project
And a team
When the team documents the project
Then team members follow guidelines provided at
http://docness.readthedocs.org/
And reference it in the project's documentation.
Scope
=====
This project mainly deals with documentation you write within a dedicated tool,
i.e. not docstrings (documentation within code).
Related work
============
Best practices and vision are not enough. We need productivity tools:
* Coding standards. Here is a `style guide for Sphinx-based documentations`_.
* Templates, snippets and content generators. Here are `templates for
Sphinx-based documentations`_.
*****
Usage
*****
* Read and follow `documentation best practices`_.
* Reference it in your own's project's documentation.
**********
Contribute
**********
Create tickets
==============
Please use the `bugtracker`_ **before** starting some work:
* check if the bug or feature request has already been filed. It may have been
answered too!
* else create a new ticket.
* if you plan to contribute, tell us, but don't wait for us! So that we are
given an opportunity to discuss, join forces or give feedback as soon as
possible.
Fork and branch
===============
* Work in forks and branches.
* Prefix your branch with the ticket ID corresponding to the issue. As an
example, if you are working on ticket #23 which is about headings convention,
name your branch like ``23-headings``.
Download and install
====================
System requirements:
* `Python`_ version 2.6 or 2.7.
.. note::
The provided Makefile uses ``python`` command. So you may use
`Virtualenv`_ to make sure the active ``python`` is the adequate one.
* Access to the Internet.
Execute:
.. code-block:: sh
git clone [email protected]/benoitbryon/docness.git
cd docness/
make install
If you cannot execute the Makefile, read it and adapt the few commands it
contains in the ``install`` section to your needs.
Hack
====
They said "Eat your own dog food", so follow:
* `style guide for Sphinx-based documentations`_
* `documentation best practices`_
In your commit messages, reference the ticket with some ``refs #TICKET-ID``
syntax.
Test and build
==============
Build the documentation and review your work before commit.
.. code-block:: sh
make build-documentation
Share
=====
* Push your code
* Submit a pull request
**********
References
**********
.. target-notes::
.. _`code repository`: https://github.com/benoitbryon/docness
.. _`bugtracker`: https://github.com/benoitbryon/docness/issues
.. _`online documentation`: http://docness.readthedocs.org/
.. _`give feedback`: https://github.com/benoitbryon/docness/issues
.. _`style guide for Sphinx-based documentations`:
https://github.com/benoitbryon/documentation-style-guide-sphinx
.. _`templates for Sphinx-based documentations`:
https://github.com/benoitbryon/documentation-templates-sphinx
.. _`Python`: http://python.org
.. _`Virtualenv`: http://virtualenv.org
.. _`documentation best practices`: http://docness.readthedocs.org/