<p dir="ltr"><br>
On 21/08/2014 10:27 pm, "Nathan Woodrow" <<a href="mailto:madmanwoo@gmail.com">madmanwoo@gmail.com</a>> wrote:<br>
><br>
> Hey all,<br>
><br>
> I would like to raise something I have been considering for a while now. We are becoming a large project, in code and users, and there has been some recent issues of developers doing work only for there to be disagreements on the implementation. I would like resurrect the use of RFCs, or I think would should name them QEP (QGIS Enhancement Proposal because that sounds much cooler :)<br>

><br>
> Thoughts?</p>
<p dir="ltr">I'm strongly in favor of this idea, and for formalizing the commit/development process in general. Like Larry mentioned, we'd need some guidelines about what kind of changes are OK just to push through without a QEP.</p>

<p dir="ltr">I'm also curious about time lines, given that often pull requests sit with no response for many months (years?). Would there be an automatic acceptance after a set time with no -1s?</p>
<p dir="ltr">On a related note, I'd also like to see some additional rules put in place around acceptable commits:<br>
- all commits which modify CORE components should be accompanied by unit tests, unless exemption is granted in advance by the dev list. GUI and app would be immune due to the difficulties in implementing ui tests<br>
- all api changes should include detailed documentation, including a description of all variables and their use</p>
<p dir="ltr">This is probably a discussion for another thread though...</p>
<p dir="ltr">Nyall</p>