<div dir="ltr">You may want to mention that persistence can go a long way as well.&nbsp; If you *really* want to see something in the trunk, prove it by keeping your patch alive, updated, and synched with the latest versions of Blender over a long period of time.&nbsp; This shows the &quot;insiders&quot; that you&#39;re committed and are not going to just dump a patch into the trunk and skip town, leaving them to maintain the code in your wake.&nbsp; It also verifies that your code is useful enough to merit inclusion.<br>
<br>Also, when developers provide feedback, it&#39;s best to try to incorporate their (hopefully constructive) criticism into your patch.&nbsp; Usually the patch will be better, you&#39;ll learn something along the way, and you&#39;ll ease the maintenance burden for later on.<br>
<br>-- Early<br><br><div class="gmail_quote">On Wed, Sep 24, 2008 at 6:35 AM, Ton Roosendaal <span dir="ltr">&lt;<a href="mailto:ton@blender.org">ton@blender.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi all,<br>
Here&#39;s a proposal for how to make patch reviewing easier, and better<br>
Below is a text proposal to include on the submission page:<br>
1) Submission guidelines<br>
Submitting patches in this tracker are very welcome! To make timely and<br>
proper reviews possible, we&#39;d recommend you to check on the guidelines<br>
- Patches solving bugs or compiling errors will usually get handled<br>
quickly. Note that for such patches we typically need similar info as<br>
for bug reports, which you can find on this page &lt;link&gt;. Especially for<br>
more complex fixes we really need to be able to verify that ourselves.<br>
- Patches providing new features are more complicated to handle. A<br>
review has to be done both on functional level (does this fit with<br>
Blender&#39;s design or roadmap) and technical level (is the provided code<br>
conform our coding style, matches design and planning, and is<br>
sufficiently readable and maintainable).<br>
- For larger patches it&#39;s relevant to note if you seek one of the<br>
Blender project members to submit and maintain it, or whether you<br>
propose to get involved as team member to maintain/improve it in the<br>
- Provide as much relevant documentation as possible. Images,<br>
screenshots, short video clips or .blend file examples do do wonders!<br>
Attach all of this in the tracker itself, or a website which you know<br>
will remain accessible for a long while.<br>
2) How to get a review<br>
Doing a good review can take a lot of time, and because almost all<br>
regular Blender developers are volunteers, we cannot make a promise<br>
you&#39;ll get such a review here! Below are tips how to get reviews done:<br>
- The most efficient way is to contact the maintainers of the code<br>
yourself. You could actually do this in advance even, to verify if your<br>
proposed work would make a good chance for inclusion. You can best find<br>
maintainers of code by reviewing svn commit history in svn &lt;link&gt;. Also<br>
check on the maintainers page &lt;link&gt; and consider to join one of our<br>
communication channels via the Get Involved page &lt;link&gt;.<br>
- When the patch has actual new functionality, user reviews will help a<br>
lot too. A lot of patches were tested first by providing public builds<br>
via websites like <a href="http://graphicall.org" target="_blank">graphicall.org</a>, or via forums on <a href="http://www.blender.org" target="_blank">www.blender.org</a> or<br>
<a href="http://www.blenderartists.org" target="_blank">www.blenderartists.org</a>.<br>
3) The review process<br>
We recommend every of the active Blender developers to spend some time<br>
on reviewing patches. In the past we&#39;ve done that a lot, and with a bit<br>
of luck you&#39;ll get great comments and advise for how to improve it.<br>
However... to prevent people to feel obliged to spend time on lengthy<br>
review discussions we also add a grading convention:<br>
- A patch review can be a simple comment only saying &quot;+1&quot; (I like it)<br>
or &quot;-1&quot; (I don&#39;t like it). No justifications are needed for that, nor a<br>
note whether this is about functionality or implementation.<br>
- Getting three &quot;+1&quot; marks from current bf-blender team members &lt;link&gt;<br>
means that your patch gets the highest priority for review, discussed<br>
in our weekly irc meetings and assigned to one of the maintainers for a<br>
serious review.<br>
Other people&#39;s votes will only be viewed as an indication.<br>
- Getting three &quot;-1&quot; marks from current bf-blender team members will<br>
allow us to close the patch without further explanation.<br>
- When positive or negative marks both occur, we&#39;ll sum the total and<br>
apply the rules above.<br>
4) Help my patch got rejected!<br>
First of all, we&#39;re all software developers here, and we understand<br>
code work on Blender shows a lot of commitment, and has been your time<br>
investment with all the good intentions to help us out. A rejection<br>
doesn&#39;t mean we don&#39;t like you, nor that we don&#39;t like to see actively<br>
helping out as a contributor! It&#39;s all human beings here, with personal<br>
preferences, and ideas for how to make Blender a better product. It<br>
makes Blender as an open source project strong if we allow active<br>
developers and maintainers to make individual choices too. They&#39;re<br>
getting empowered to do development, which also implies they have get<br>
the benefit of the doubt in making tough decisions.<br>
Nevertheless, mistakes can always happen! Here&#39;s what to do to get a<br>
patch considered after all:<br>
- Contact the developer list with a friendly request for (additional)<br>
reviews. Make sure the current maintainer of code at least is aware of<br>
this rejection.<br>
- If no result or consensus in the project team can be found, you can<br>
ask the &#39;admins&#39; of bf-blender to provide a final verdict (Matt,<br>
Willian, Martin, Ton).<br>
Ton Roosendaal &nbsp;Blender Foundation &nbsp; <a href="mailto:ton@blender.org">ton@blender.org</a> &nbsp; &nbsp;<a href="http://www.blender.org" target="_blank">www.blender.org</a><br>
Blender Institute BV &nbsp;Entrepotdok 57A &nbsp;1018AD Amsterdam The Netherlands<br>
Bf-committers mailing list<br>
<a href="mailto:Bf-committers@blender.org">Bf-committers@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-committers" target="_blank">http://lists.blender.org/mailman/listinfo/bf-committers</a><br>