1 |
|
---|
2 | =encoding utf8
|
---|
3 |
|
---|
4 | =head1 NAME
|
---|
5 |
|
---|
6 | Mojolicious::Guides::Contributing - Contributing to Mojolicious
|
---|
7 |
|
---|
8 | =head1 OVERVIEW
|
---|
9 |
|
---|
10 | There are many ways to contribute to L<Mojolicious>, this guide will show you a
|
---|
11 | few of them.
|
---|
12 |
|
---|
13 | =head1 REPORTING BUGS
|
---|
14 |
|
---|
15 | We use the L<GitHub issue tracker|https://github.com/kraih/mojo/issues>, so
|
---|
16 | you'll need to create a (free) GitHub account to be able to submit issues,
|
---|
17 | comments and pull requests.
|
---|
18 |
|
---|
19 | First of all, make sure you are using the latest version of L<Mojolicious>, it
|
---|
20 | is quite likely that your bug has already been fixed. If that doesn't help,
|
---|
21 | take a look at the list of currently open issues, perhaps it has already been
|
---|
22 | reported by someone else and you can just add a comment confirming it.
|
---|
23 |
|
---|
24 | If it hasn't been reported yet, try to prepare a test case demonstrating the
|
---|
25 | bug, you are not expected to fix it yourself, but you'll have to make sure the
|
---|
26 | developers can replicate your problem. Sending in your whole application
|
---|
27 | generally does more harm than good, the C<t> directory of this distribution has
|
---|
28 | many good examples for how to do it right. Writing a test is usually the
|
---|
29 | hardest part of fixing a bug, so the better your test case the faster it can be
|
---|
30 | fixed. ;)
|
---|
31 |
|
---|
32 | And don't forget to add a descriptive title and text, when you create a new
|
---|
33 | issue. If your issue does not contain enough information or is unintelligible,
|
---|
34 | it might get closed pretty quickly. But don't be disheartened, if there's new
|
---|
35 | activity it will get reopened just as quickly.
|
---|
36 |
|
---|
37 | =head2 Reporting security issues
|
---|
38 |
|
---|
39 | Please report security issues directly to the pumpkin-holder via email, which is
|
---|
40 | currently Sebastian Riedel (C<[email protected]>), and give us a few days to
|
---|
41 | develop and release a proper fix.
|
---|
42 |
|
---|
43 | =head1 RESOLVING ISSUES
|
---|
44 |
|
---|
45 | There are many ways in which you can help us resolve existing issues on the
|
---|
46 | L<GitHub issue tracker|https://github.com/kraih/mojo/issues>.
|
---|
47 |
|
---|
48 | Can you replicate the problem on your computer? Add a comment saying that
|
---|
49 | you're seeing the same. Perhaps you can provide additional information that
|
---|
50 | will make it easier for others to replicate the problem, maybe even contribute
|
---|
51 | a better test case.
|
---|
52 |
|
---|
53 | And for all code contributions we very much appreciate additional testing and
|
---|
54 | code review, just add a comment to show your approval or to point out flaws
|
---|
55 | that need to be addressed.
|
---|
56 |
|
---|
57 | =head1 CONTRIBUTING DOCUMENTATION
|
---|
58 |
|
---|
59 | One of the easiest ways to contribute to L<Mojolicious> is through
|
---|
60 | documentation improvements. While the L<Mojolicious::Guides> are carefully
|
---|
61 | curated by the core team, everybody with a (free) GitHub account can make
|
---|
62 | changes and add new information to the
|
---|
63 | L<Mojolicious wiki|http://github.com/kraih/mojo/wiki>.
|
---|
64 |
|
---|
65 | Pull requests with additions or changes to the documentation included in the
|
---|
66 | L<Mojolicious> distribution follow the same rules as code contributions. Please
|
---|
67 | don't send pull requests for overly simplistic changes, such as the addition of
|
---|
68 | a comma or semicolon.
|
---|
69 |
|
---|
70 | =head1 CONTRIBUTING CODE
|
---|
71 |
|
---|
72 | All code contributions should be sent as
|
---|
73 | L<GitHub pull requests|https://help.github.com/articles/using-pull-requests>.
|
---|
74 |
|
---|
75 | An expressive title and detailed description are invaluable during the review
|
---|
76 | process, which usually ends when members of the community have voiced their
|
---|
77 | opinions and the core team voted for or against a change. All code changes
|
---|
78 | should emulate the style of the surrounding code, include tests that fail
|
---|
79 | without them, and update relevant documentation.
|
---|
80 |
|
---|
81 | While the L<Mojolicious> distribution covers a wide range of features, we are
|
---|
82 | rather conservative when it comes to adding new ones. So if your contribution
|
---|
83 | is not a simple bug fix, it is B<strongly recommended> that you discuss it in
|
---|
84 | advance on the L<mailing list|http://groups.google.com/group/mojolicious> or the
|
---|
85 | official IRC channel C<#mojo> on C<irc.perl.org>
|
---|
86 | (L<chat now!|https://chat.mibbit.com/?channel=%23mojo&server=irc.perl.org>), to
|
---|
87 | avoid unnecessary work and to increase its chances of getting accepted.
|
---|
88 |
|
---|
89 | The following mission statement and rules are the foundation of all L<Mojo> and
|
---|
90 | L<Mojolicious> development. Please make sure that your contribution aligns well
|
---|
91 | with them before sending a pull request.
|
---|
92 |
|
---|
93 | =head2 Mission statement
|
---|
94 |
|
---|
95 | L<Mojo> is a web development toolkit, with all the basic tools and helpers
|
---|
96 | needed to write simple web applications and higher level web frameworks, such as
|
---|
97 | L<Mojolicious>.
|
---|
98 |
|
---|
99 | All components should be reusable in other projects, and in a UNIXish way only
|
---|
100 | loosely coupled.
|
---|
101 |
|
---|
102 | Especially for people new to Perl it should be as easy as possible to install
|
---|
103 | L<Mojolicious> and get started. Writing web applications can be one of the most
|
---|
104 | fun ways to learn a language!
|
---|
105 |
|
---|
106 | For developers of other web frameworks, it should be possible to reuse all the
|
---|
107 | infrastructure and just consider the higher levels of the L<Mojolicious>
|
---|
108 | distribution an example application.
|
---|
109 |
|
---|
110 | =head2 Rules
|
---|
111 |
|
---|
112 | =over 2
|
---|
113 |
|
---|
114 | Web development should be easy and fun, this is what we optimize for.
|
---|
115 |
|
---|
116 | The web is a moving target, to stay relevant we have to stay in motion too.
|
---|
117 |
|
---|
118 | Keep it simple, no magic unless absolutely necessary.
|
---|
119 |
|
---|
120 | The installation process should be as fast and painless as possible. (Less than
|
---|
121 | a minute on most common hardware is a good rule of thumb)
|
---|
122 |
|
---|
123 | The addition and modification of features is decided by majority vote or the
|
---|
124 | pumpkin-holder.
|
---|
125 |
|
---|
126 | Any core developer may nominate a new one, who must then be accepted by a 2/3
|
---|
127 | majority vote.
|
---|
128 |
|
---|
129 | The pumpkin-holder has veto rights and may select their successor.
|
---|
130 |
|
---|
131 | It's not a feature without a test and documentation.
|
---|
132 |
|
---|
133 | A feature is only needed when the majority of the user base benefits from it.
|
---|
134 |
|
---|
135 | Features may only be changed in a major release, to fix a serious security
|
---|
136 | issue, or after being deprecated for at least 3 months.
|
---|
137 |
|
---|
138 | Refactoring and deprecations should be avoided if there are no substantial
|
---|
139 | benefits.
|
---|
140 |
|
---|
141 | New features can be marked as experimental to be excluded from deprecation
|
---|
142 | policies.
|
---|
143 |
|
---|
144 | A major release is signaled by a new major version number and a unique code
|
---|
145 | name based on a Unicode character.
|
---|
146 |
|
---|
147 | Only add dependencies if absolutely necessary and make them optional if
|
---|
148 | possible.
|
---|
149 |
|
---|
150 | Domain specific languages should be avoided in favor of Perl-ish solutions.
|
---|
151 |
|
---|
152 | No inline POD.
|
---|
153 |
|
---|
154 | Documentation belongs to the guides, module POD is just an API reference.
|
---|
155 |
|
---|
156 | The main focus of the included documentation should be on examples, no walls of
|
---|
157 | text. (An example for every one or two sentences is a good rule of thumb)
|
---|
158 |
|
---|
159 | Everything should be ordered alphabetically if possible, or at least be
|
---|
160 | consistent if not.
|
---|
161 |
|
---|
162 | The master source code repository should always be kept in a stable state, use
|
---|
163 | feature branches for actual development.
|
---|
164 |
|
---|
165 | Code has to be run through L<Perl::Tidy> with the included
|
---|
166 | L<.perltidyrc|https://github.com/kraih/mojo/blob/master/.perltidyrc>, and
|
---|
167 | everything should look like it was written by a single person.
|
---|
168 |
|
---|
169 | Functions and methods should be as short as possible, no spaghetti code.
|
---|
170 |
|
---|
171 | Comments should be correctly capitalized, and funny if possible, punctuation is
|
---|
172 | optional if it doesn't increase readability.
|
---|
173 |
|
---|
174 | No names outside of C<Mojolicious.pm>.
|
---|
175 |
|
---|
176 | =back
|
---|
177 |
|
---|
178 | =head1 DONATIONS
|
---|
179 |
|
---|
180 | L<Mojolicious> is open source and free to use. However, the amount of effort
|
---|
181 | needed to maintain the project and develop new features for it is not
|
---|
182 | sustainable without proper financial backing. You can support the ongoing
|
---|
183 | development of L<Mojolicious> through L<PayPal|https://www.paypal.me/kraih>.
|
---|
184 |
|
---|
185 | If you run a business and use L<Mojolicious> in a revenue generating product, it
|
---|
186 | makes business sense to support L<Mojolicious> development. Because it ensures
|
---|
187 | that the project your product relies on stays healthy and actively maintained.
|
---|
188 | It can also help your exposure within the community and will make it easier to
|
---|
189 | attract L<Mojolicious> developers.
|
---|
190 |
|
---|
191 | Please email Sebastian Riedel (C<[email protected]>) if you have any
|
---|
192 | questions about becoming a sponsor.
|
---|
193 |
|
---|
194 | =head1 CODE OF CONDUCT
|
---|
195 |
|
---|
196 | Like the technical community as a whole, the L<Mojolicious> team and community
|
---|
197 | is made up of a mixture of professionals and volunteers from all over the world,
|
---|
198 | working on every aspect of the mission - including mentorship, teaching, and
|
---|
199 | connecting people.
|
---|
200 |
|
---|
201 | Diversity is one of our huge strengths, but it can also lead to communication
|
---|
202 | issues and unhappiness. To that end, we have a few ground rules that we ask
|
---|
203 | people to adhere to. This code applies equally to founders, mentors and those
|
---|
204 | seeking help and guidance.
|
---|
205 |
|
---|
206 | This isnât an exhaustive list of things that you canât do. Rather, take it in
|
---|
207 | the spirit in which itâs intended - a guide to make it easier to enrich all of
|
---|
208 | us and the technical communities in which we participate.
|
---|
209 |
|
---|
210 | This code of conduct applies to all spaces managed by the L<Mojolicious>
|
---|
211 | project. This includes IRC, the mailing lists, the issue tracker, and any other
|
---|
212 | forums created by the project team which the community uses for communication.
|
---|
213 | In addition, violations of this code outside these spaces may affect a person's
|
---|
214 | ability to participate within them.
|
---|
215 |
|
---|
216 | If you believe someone is violating the code of conduct, we ask that you report
|
---|
217 | it by emailing Joel Berger (C<[email protected]>) or other members of
|
---|
218 | L<the team|Mojolicious/"CORE DEVELOPERS">.
|
---|
219 |
|
---|
220 | =over 2
|
---|
221 |
|
---|
222 | =item * B<Be friendly and patient.>
|
---|
223 |
|
---|
224 | =item * B<Be welcoming.> We strive to be a community that welcomes and supports
|
---|
225 | people of all backgrounds and identities. This includes, but is not limited to
|
---|
226 | members of any race, ethnicity, culture, national origin, colour, immigration
|
---|
227 | status, social and economic class, educational level, sex, sexual orientation,
|
---|
228 | gender identity and expression, age, size, family status, political belief,
|
---|
229 | religion, and mental and physical ability.
|
---|
230 |
|
---|
231 | =item * B<Be considerate.> Your work will be used by other people, and you in
|
---|
232 | turn will depend on the work of others. Any decision you take will affect users
|
---|
233 | and colleagues, and you should take those consequences into account when making
|
---|
234 | decisions. Remember that we're a world-wide community, so you might not be
|
---|
235 | communicating in someone else's primary language.
|
---|
236 |
|
---|
237 | =item * B<Be respectful.> Not all of us will agree all the time, but
|
---|
238 | disagreement is no excuse for poor behavior and poor manners. We might all
|
---|
239 | experience some frustration now and then, but we cannot allow that frustration
|
---|
240 | to turn into a personal attack. Itâs important to remember that a community
|
---|
241 | where people feel uncomfortable or threatened is not a productive one. Members
|
---|
242 | of the L<Mojolicious> community should be respectful when dealing with other
|
---|
243 | members as well as with people outside the L<Mojolicious> community.
|
---|
244 |
|
---|
245 | =item * B<Be careful in the words that you choose.> We are a community of
|
---|
246 | professionals, and we conduct ourselves professionally. Be kind to others. Do
|
---|
247 | not insult or put down other participants. Harassment and other exclusionary
|
---|
248 | behavior aren't acceptable. This includes, but is not limited to:
|
---|
249 |
|
---|
250 | =over 2
|
---|
251 |
|
---|
252 | =item * Violent threats or language directed against another person.
|
---|
253 |
|
---|
254 | =item * Discriminatory jokes and language.
|
---|
255 |
|
---|
256 | =item * Posting sexually explicit or violent material.
|
---|
257 |
|
---|
258 | =item * Posting (or threatening to post) other people's personally identifying
|
---|
259 | information ("doxing").
|
---|
260 |
|
---|
261 | =item * Personal insults, especially those using racist or sexist terms.
|
---|
262 |
|
---|
263 | =item * Unwelcome sexual attention.
|
---|
264 |
|
---|
265 | =item * Advocating for, or encouraging, any of the above behavior.
|
---|
266 |
|
---|
267 | =item * Repeated harassment of others. In general, if someone asks you to stop,
|
---|
268 | then stop.
|
---|
269 |
|
---|
270 | =back
|
---|
271 |
|
---|
272 | =item * B<When we disagree, try to understand why.> Disagreements, both social
|
---|
273 | and technical, happen all the time and L<Mojolicious> is no exception. It is
|
---|
274 | important that we resolve disagreements and differing views constructively.
|
---|
275 | Remember that weâre different. The strength of L<Mojolicious> comes from its
|
---|
276 | varied community, people from a wide range of backgrounds. Different people have
|
---|
277 | different perspectives on issues. Being unable to understand why someone holds a
|
---|
278 | viewpoint doesnât mean that theyâre wrong. Donât forget that it is human to err
|
---|
279 | and blaming each other doesnât get us anywhere. Instead, focus on helping to
|
---|
280 | resolve issues and learning from mistakes.
|
---|
281 |
|
---|
282 | =back
|
---|
283 |
|
---|
284 | =head1 FORK POLICY
|
---|
285 |
|
---|
286 | The L<Mojolicious> core team believes that there is a lot of value in the entire
|
---|
287 | toolkit being a unified project. Forks drain resources from a project, not just
|
---|
288 | mindshare but also very valuable bug reports and patches, which can have very
|
---|
289 | serious security implications. Therefore we ask that you please not publically
|
---|
290 | fork pieces of the L<Mojolicious> distribution without our consent. As doing so
|
---|
291 | is against our express wishes, individuals who engage in unauthorized forking
|
---|
292 | may be denied from participating in community sponsored spaces.
|
---|
293 |
|
---|
294 | For developers considering the use of a forked module, we strongly recommend
|
---|
295 | that you make yourself familiar with its history and track record. While many
|
---|
296 | parts of L<Mojolicious> have been forked in the past, very few forks have been
|
---|
297 | able to keep up with L<Mojolicious> development, and most are missing critical
|
---|
298 | bug fixes.
|
---|
299 |
|
---|
300 | =head1 MORE
|
---|
301 |
|
---|
302 | You can continue with L<Mojolicious::Guides> now or take a look at the
|
---|
303 | L<Mojolicious wiki|http://github.com/kraih/mojo/wiki>, which contains a lot more
|
---|
304 | documentation and examples by many different authors.
|
---|
305 |
|
---|
306 | =head1 SUPPORT
|
---|
307 |
|
---|
308 | If you have any questions the documentation might not yet answer, don't
|
---|
309 | hesitate to ask on the
|
---|
310 | L<mailing list|http://groups.google.com/group/mojolicious> or the official IRC
|
---|
311 | channel C<#mojo> on C<irc.perl.org>
|
---|
312 | (L<chat now!|https://chat.mibbit.com/?channel=%23mojo&server=irc.perl.org>).
|
---|
313 |
|
---|
314 | =cut
|
---|