You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<p>The maintainers and members of the community generally like seeing well-prepared proposals for libraries to be included. The reason for this is so that we waste as little time from everyone who's going to be involved in the process as possible. Therefore we ask that before you bring an idea to the table, please prepare the following information (even only when sending an email to the mailing list).</p>
50
+
<p>The maintainers and members of the community generally like
51
+
seeing well-prepared proposals for libraries to be included. The
52
+
reason for this is so that we waste as little time from everyone
53
+
who's going to be involved in the process as possible. Therefore
54
+
we ask that before you bring an idea to the table, please prepare
55
+
the following information (even only when sending an email to the
56
+
mailing list).</p>
51
57
<ul>
52
-
<li><strong>Problem Statement.</strong> It's surprisingly hard to evaluate proposals without a problem being solved. To make it easier to evaluate proposals, please define what problem you're intending to solve with the library you're proposing to include (if it's already there, that's good — if it's going to be developed from scratch, it's easier to know what the problem is before we start).</li>
53
-
<li><strong>User Stories.</strong> We generally like to evaluate libraries based on how easy it is for users to use. It is then paramout that you present a vision on how users of the library will be using the library. Examples of user code would be most appreciated.</li>
54
-
<li><strong>Scope and Goals.</strong> Knowing what the scope of your library will be is better generally so that interested parties who want to help in development and maintenance can see whether they can help or whether you can do it all on your own. Knowing what you want to accomplish and sharing those with the community of users and developers gives everyone the same ideas as to what to expect.</li>
55
-
<li><strong>Design Documentation.</strong> API design is hard, and having a high level idea of how things will be implemented in your library makes it easier to see the bigger picture. This document need not be too formal but it should be something self-contained and easily modified/commented-on for a lower collaboration bar. Please do not put your design document as an email — a Wiki document, shared Google Document, or a GitHub repository is much easier to discuss than an email.</li>
58
+
<li><strong>Problem Statement.</strong> It's surprisingly hard to
59
+
evaluate proposals without a problem being solved. To make it
60
+
easier to evaluate proposals, please define what problem you're
61
+
intending to solve with the library you're proposing to include
62
+
(if it's already there, that's good — if it's going to be
63
+
developed from scratch, it's easier to know what the problem is
64
+
before we start).</li>
65
+
<li><strong>User Stories.</strong> We generally like to evaluate
66
+
libraries based on how easy it is for users to use. It is then
67
+
paramout that you present a vision on how users of the library
68
+
will be using the library. Examples of user code would be most
69
+
appreciated.</li>
70
+
<li><strong>Scope and Goals.</strong> Knowing what the scope of
71
+
your library will be is better generally so that interested
72
+
parties who want to help in development and maintenance can see
73
+
whether they can help or whether you can do it all on your own.
74
+
Knowing what you want to accomplish and sharing those with the
75
+
community of users and developers gives everyone the same ideas
76
+
as to what to expect.</li>
77
+
<li><strong>Design Documentation.</strong> API design is hard,
78
+
and having a high level idea of how things will be implemented in
79
+
your library makes it easier to see the bigger picture. This
80
+
document need not be too formal but it should be something
81
+
self-contained and easily modified/commented-on for a lower
82
+
collaboration bar. Please do not put your design document as an
83
+
email — a Wiki document, shared Google Document, or a
84
+
GitHub repository is much easier to discuss than an email.</li>
56
85
</ul>
57
-
<p>Once you have these things, fire off an email to the mailing list citing the above four preparation sections.<p>
86
+
<p>Once you have these things, fire off an email to the mailing
87
+
list citing the above four preparation sections.<p>
58
88
</section>
59
89
<sectionid="discussion">
60
90
<divclass="page-header">
61
91
<h1>Discussion</h1>
62
92
</div>
63
-
<p>All discussions should occur in the mailing list for issues not related to the design documentation. If the design doc is a shared Google Document comments will be made on the document itself. For everything else, the discussions should be done on the mailing list.</p>
64
-
<p>The discussion will be considered concluded when all the maintainers of the library agree that the proposal makes sense and that it's something the community wants to have in the library. The process will be tracked by a formal survey on the mailing list run by one of the maintainers.</p>
65
-
<p>Once everybody's convinced that things should move forward, then maintainers and interested contributors hunker down to start collaborating on the development of the library.</p>
93
+
<p>All discussions should occur in the mailing list for issues
94
+
not related to the design documentation. If the design doc is a
95
+
shared Google Document comments will be made on the document
96
+
itself. For everything else, the discussions should be done on
97
+
the mailing list.</p>
98
+
<p>The discussion will be considered concluded when all the
99
+
maintainers of the library agree that the proposal makes sense
100
+
and that it's something the community wants to have in the
101
+
library. The process will be tracked by a formal survey on the
102
+
mailing list run by one of the maintainers.</p>
103
+
<p>Once everybody's convinced that things should move forward,
104
+
then maintainers and interested contributors hunker down to start
105
+
collaborating on the development of the library.</p>
66
106
</section>
67
107
<sectionid="collaboration">
68
108
<divid="page-header">
69
109
<h1>Collaboration</h1>
70
110
</div>
71
-
<p>The collaboration process is intended to be much simpler: all discussions on progress and questions to clarify happen on the mailing list. Matters affecting progress — developers missing in action, thorny implementation details, blockers, and style questions should be discussed all in the open. We encourage this so that everyone in the community is involved in the process where we exclude nobody's opinion and contributions.</p>
72
-
<p>As far as development is concerned, there are two main ways of getting the development done. Each one has its merits so we present both.</p>
111
+
<p>The collaboration process is intended to be much simpler: all
112
+
discussions on progress and questions to clarify happen on the
missing in action, thorny implementation details, blockers, and
115
+
style questions should be discussed all in the open. We encourage
116
+
this so that everyone in the community is involved in the process
117
+
where we exclude nobody's opinion and contributions.</p>
118
+
<p>As far as development is concerned, there are two main ways of
119
+
getting the development done. Each one has its merits so we
120
+
present both.</p>
73
121
<h2>Fork of cpp-netlib</h2>
74
-
<p>The fork process is straight-forward — whoever proposed the library and those who have pledged to contribute to the implementation shall fork the main repository and develop in parallel as the main repository. They can send progress reports to the main developer list and have the partially complete work merged into the master branch as it gets completed. All changes can be isolated to an external fork where changes are meant to be integrated before being submitted in bulk to the main repo as a single PR.</p>
75
-
<p>This process effectively promotes whomever is driving and owning the process as a maintainer of cpp-netlib. The downside to this is that it's a lot of responsibility and may be time consuming.</p>
122
+
<p>The fork process is straight-forward — whoever proposed
123
+
the library and those who have pledged to contribute to the
124
+
implementation shall fork the main repository and develop in
125
+
parallel as the main repository. They can send progress reports
126
+
to the main developer list and have the partially complete work
127
+
merged into the master branch as it gets completed. All changes
128
+
can be isolated to an external fork where changes are meant to be
129
+
integrated before being submitted in bulk to the main repo as a
130
+
single PR.</p>
131
+
<p>This process effectively promotes whomever is driving and
132
+
owning the process as a maintainer of cpp-netlib. The downside to
133
+
this is that it's a lot of responsibility and may be time
134
+
consuming.</p>
76
135
<h2>Submodule to cpp-netlib</h2>
77
-
<p>The submodule approach is much more decoupled and allows for having the implemented library be as stand-alone as possible. Some libraries in cpp-netlib are already submodules and are maintained separately by the corresponding maintainer.</p>
78
-
<p>The problem with this approach is that coordinating breaking changes on multiple interacting submodules will be much harder. It also makes the release/development process much more cumbersome than the fork model. It also makes it harder to enforce the style guide and development processes on the submodule.</p>
136
+
<p>The submodule approach is much more decoupled and allows for
137
+
having the implemented library be as stand-alone as possible.
138
+
Some libraries in cpp-netlib are already submodules and are
139
+
maintained separately by the corresponding maintainer.</p>
140
+
<p>The problem with this approach is that coordinating breaking
141
+
changes on multiple interacting submodules will be much harder.
142
+
It also makes the release/development process much more
143
+
cumbersome than the fork model. It also makes it harder to
144
+
enforce the style guide and development processes on the
145
+
submodule.</p>
79
146
<h2>Preferred Mode</h2>
80
-
<p>The preferred mode of development is the fork model, where coordination is much closer and much more explicit. It also allows the maintainers to easily cut releases and maintain a single repository unto which all changes and history can be kept.</p>
81
-
<p>Only in rare circumstances will a submodule actually be preferred — for instance, if the project has already been in existence before being accepted into <code>cpp-netlib</code> or if it's made sufficiently stand-alone for purposes of inclusion into the standard library.</p>
147
+
<p>The preferred mode of development is the fork model, where
148
+
coordination is much closer and much more explicit. It also
149
+
allows the maintainers to easily cut releases and maintain a
150
+
single repository unto which all changes and history can be
151
+
kept.</p>
152
+
<p>Only in rare circumstances will a submodule actually be
153
+
preferred — for instance, if the project has already been
154
+
in existence before being accepted into <code>cpp-netlib</code>
155
+
or if it's made sufficiently stand-alone for purposes of
156
+
inclusion into the standard library.</p>
82
157
</section>
83
158
<sectionid="inclusion">
84
159
<divclass="page-header">
85
160
<h1>Inclusion</h1>
86
161
</div>
87
-
<p>Inclusion entails three specific things which will differentiate any other library from an accepted <code>cpp-netlib</code> library.</p>
162
+
<p>Inclusion entails three specific things which will
163
+
differentiate any other library from an accepted
164
+
<code>cpp-netlib</code> library.</p>
88
165
<ul>
89
-
<li><strong>Maintainership.</strong> All current maintainers of <code>cpp-netlib</code> get maintainership over the library that's accepted, and the proposer and main developers of the library become maintainers of <code>cpp-netlib</code> as well. We usually defer library-specific issues to the main library maintainer/developer but in case of whole-library and community decisions all maintainers get the same responibilities.</li>
90
-
<li><strong>Support.</strong> Any included library shall be supported by the community and maintainers until it is either removed or retired.</li>
91
-
<li><strong>Distribution.</strong> Any library included into <code>cpp-netlib</code> shall be distributed as part of the main distribution.
166
+
<li><strong>Maintainership.</strong> All current maintainers of
167
+
<code>cpp-netlib</code> get maintainership over the library
168
+
that's accepted, and the proposer and main developers of the
169
+
library become maintainers of <code>cpp-netlib</code> as well. We
170
+
usually defer library-specific issues to the main library
171
+
maintainer/developer but in case of whole-library and community
172
+
decisions all maintainers get the same responibilities.</li>
173
+
<li><strong>Support.</strong> Any included library shall be
174
+
supported by the community and maintainers until it is either
175
+
removed or retired.</li>
176
+
<li><strong>Distribution.</strong> Any library included into
177
+
<code>cpp-netlib</code> shall be distributed as part of the main
178
+
distribution.
92
179
</ul>
93
-
<p>On the note about maintainership — once someone is promoted to maintainer of cpp-netlib, that person gets administrative rights to the project repository. In the event that someone becomes inactive or relinquishes the role, only then will that person be considered an ex-maintainer.</p>
94
-
<p>This means, once someone is deemed a maintainer, he'll always be considered a maintainer unless he becomes inactive or relinquishes that role.</p>
180
+
<p>On the note about maintainership — once someone is
181
+
promoted to maintainer of cpp-netlib, that person gets
182
+
administrative rights to the project repository. In the event
183
+
that someone becomes inactive or relinquishes the role, only then
184
+
will that person be considered an ex-maintainer.</p>
185
+
<p>This means, once someone is deemed a maintainer, he'll always
186
+
be considered a maintainer unless he becomes inactive or
0 commit comments