pages tagged contributingyakkinghttp://yakking.branchable.com/tags/contributing/yakkingikiwiki2017-03-01T12:00:15ZFacilitating is no less valuable than contributinghttp://yakking.branchable.com/posts/facilitating/Richard Maw2017-03-01T12:00:15Z2017-03-01T12:00:07Z
<p>FOSS projects are mostly developed on a volunteer basis.</p>
<p>This makes the currencies by which they are developed: free time and motivation.</p>
<p>Often times you have the free time, but not the motivation.
Often this is not from feeling that the work isn't worth doing,
but that you feel inadequate to do it.</p>
<p>Don't be disheartened.
There's plenty you can do that helps.</p>
<ol>
<li><p>Just be there, whether in-person or online.</p>
<p>You can do whatever else you want while being there,
but it's encouraging to not be along in your endeavours.</p>
<p>You may even find some motivation of your own.</p></li>
<li><p>When others are talking about what they want to achieve,
respond enthusiastically.</p>
<p>It makes them more likely to follow-through and do so,
and in the very least makes them feel good.</p>
<p>This does risk making them feel worse if they never get around to it,
but sometimes that's sufficient to shame them into action later,
and other times it's sufficient to say "these things happen".</p></li>
<li><p>Engage in discussion about what others want to achieve.</p>
<p>It's extremely valuable for refining ideas,
so they can implement what they want to do better,
it keeps it fresh in their mind so motivation lasts longer,
and it leaves a clearer idea of what to do
so it may be completed before motivation runs out.</p></li>
<li><p>Mention what other people are doing to people who might be interested.</p>
<p>You could end up with anecdotes of other people thinking it's a cool idea,
which when relayed to people doing the work provides their own motivation.</p></li>
<li><p>Remind people of the successes they've had.</p>
<p>It makes people feel good about what they've already done,
and can put any issues they are currently struggling with into perspective.</p>
<p>Lars pointed out that
Yakking has published more than 180 articles at a rate of one per week!
We've managed to get this far, we can continue for a good while yet.</p></li>
</ol>
Contributing to someone else's projecthttp://yakking.branchable.com/posts/contributing/Lars Wirzenius2014-01-08T12:00:23Z2014-01-08T12:00:07Z
<p>There are a lot of free software projects out there, and you'll likely
want to contribute to at least one of them. It might be in the form of
a good bug report, a fix for a bug, some documentation, a new feature,
translation to another natural language, or something else. There are
numerous forms of contributions, and they're all valuable and
necessary.</p>
<p>A contribution may be a quick, one-time thing, or a long-term
committment to the project. Both are good. Free software thrives on
drive-by patch submissions, but of course some people need to
participate in each project more or less permanently.</p>
<p>As a very important point, note that you do not need to be an expert
to contribute. Nobody cares if you have a PhD or not, as long as you
make things better. Even if it is only a teeny, tiny little spelling
mistake, it's almost always welcomed.</p>
<p>There are some things to keep in mind though, for things to go well.</p>
<ul>
<li>First of all, be polite. Don't show up on the project mailing list
telling everyone how stupid they are for not having fixed this
problem already.</li>
<li>As part of being polite, be patient. Don't push, don't nag. Many
high-visibility free software projects are developed by people who
are very busy people, and it may take a while for them to have time
for you. You don't need to wait forever, but give people some
reasonable time to respond before pinging them.</li>
<li>Talk to the project developers to make sure they welcome your
contribution. If you're going to be making a large change, do this
before starting work. For example, rewriting the Linux kernel in
Python turned out to be something Linus wouldn't accept, whereas
fixing a segmentation fault in gcc is always welcome.</li>
<li>As the first part of your contribution, explain why you think it's a
good idea. Explain the bug, or why a missing feature is needed, or
whatever it might be. This allows others to understand your
motivation and hopefully gets them into the right frame of mind.</li>
<li>Be prepared for negative feedback. It's possible that the way you've
done things isn't acceptable to the project, for some reason.
It might be stylistic, or perhaps they can see a better way to
design things, or maybe they can see a mistake you've done and want
you to fix that. You'll need to adapt your changes based on
feedback. That's OK, that's how peer review works. If you're
convinced the feedback you get is wrong, you can argue against it,
but do it politely.</li>
<li>License your changes the same way the project already does.</li>
<li>If the project has contribution guidelines or paths, follow them.
These usually exist in large projects, such as the Linux kernel.
Smaller projects tend to be more flexible.</li>
</ul>
<p>Some related reading:</p>
<ul>
<li><a href="http://libregraphicsworld.org/blog/entry/contributing-to-free-software-projects">http://libregraphicsworld.org/blog/entry/contributing-to-free-software-projects</a></li>
<li><a href="http://kegel.com/academy/opensource.html">http://kegel.com/academy/opensource.html</a></li>
<li><a href="http://blog.adamspiers.org/2012/11/10/7-principles-for-contributing-patches-to-software-projects/">http://blog.adamspiers.org/2012/11/10/7-principles-for-contributing-patches-to-software-projects/</a></li>
<li><a href="http://www.shlomifish.org/philosophy/computers/open-source/how-to-start-contributing/">http://www.shlomifish.org/philosophy/computers/open-source/how-to-start-contributing/</a></li>
</ul>