<?xml version="1.0" encoding="utf-8"?><!DOCTYPE article  PUBLIC '-//OASIS//DTD DocBook XML V4.4//EN'  'http://www.docbook.org/xml/4.4/docbookx.dtd'><article><articleinfo><title>HelpOnPatchCreation</title></articleinfo><para><ulink url="http://www.nnx.me/HelpOnPatchCreation/HelpContents#">HelpContents</ulink> &gt; <ulink url="http://www.nnx.me/HelpOnPatchCreation/HelpForDevelopers#">HelpForDevelopers</ulink> &gt; HelpOnPatchCreation </para><para>You found a way to fix a bug, and you like moin developer to include your fix, but you don't know how to create a patch. Here is how: </para><section><title>How to make a new patch</title><orderedlist numeration="arabic"><listitem><para>Get the latest version of the source and make your edits. <ulink url="http://moinmoin.wikiwikiweb.de/MoinDev/MercurialGuide#">MoinDev/MercurialGuide</ulink> tells you more. </para></listitem><listitem><para>Before you continue ask yourself the following questions: </para><itemizedlist><listitem><para>Is the patch useful to most users? A feature useful for you isn't necessarily useful for everybody. </para></listitem><listitem><para>Is it the <ulink url="http://moinmoin.wikiwikiweb.de/WikiWay#">WikiWay</ulink>? Doing something the WikiWay is more likely to get included than doing it in any other way. </para></listitem><listitem><para>Is this a good patch? Clean, easy to read and understand code is more likely to be included. </para></listitem><listitem><para>Have you tested the code well enough? Some of the <ulink url="http://moinmoin.wikiwikiweb.de/MoinCoreTeamGroup#">MoinCoreTeamGroup</ulink> members like tests for any code, and will not be happy to include new code without tests. </para></listitem></itemizedlist></listitem><listitem><para>Also consider this: </para><itemizedlist><listitem><para><ulink url="http://moinmoin.wikiwikiweb.de/MoinDev/GettingStarted#createplugins">Create extensions if possible</ulink>! </para></listitem><listitem><para>Smaller, cleanly separated patches are much more likely to get included than bigger, mixed ones. </para></listitem><listitem><para>Well documented code. To save time, write clear code that is self-explaining. <inlinemediaobject><imageobject><imagedata depth="16" fileref="http://www.nnx.me//moin_static197/ninuxtheme02/img/smile.png" width="16"/></imageobject><textobject><phrase>:-)</phrase></textobject></inlinemediaobject> </para></listitem><listitem><para>User documentation - if you add a feature, add user documentation. </para></listitem><listitem><para>Easy to maintain code - either you or some other developer will have to maintain the code. It should be easy, as we don't have time for this. </para></listitem></itemizedlist></listitem></orderedlist></section><section><title>Patches for current production version</title><para>These are only included if: </para><itemizedlist><listitem><para>It fixes a bug, </para></listitem><listitem><para>adds a minor (but useful) feature, </para></listitem><listitem><para>does not introduce new bugs and </para></listitem><listitem><para>is a small, clean patch. </para></listitem></itemizedlist><!--rule (<hr>) is not applicable to DocBook--></section></article>