Inline.<br><br><div class="gmail_quote">On Thu, Nov 8, 2012 at 11:47 AM, Matt Joyce <span dir="ltr"><<a href="mailto:matt@nycresistor.com" target="_blank">matt@nycresistor.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think it's a great idea to develop a process for operators to go<br>
through in suggesting work for dev teams.  One that alleviates a lot<br>
of the burden of having to know what is and is not a valid bug or blue<br>
print.  If the operations contributors can work together to self solve<br>
problems and promote real issues that's a win for everyone.  Low<br>
barrier of entry for operators of the stack, plus quality bug reports<br>
and blue prints.<br>
<br>
I really like the idea.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Me too. An advantage of this wiki approach is understanding and visualization of the pain points, from different perspectives. If an issue is clearly a feature request or bug it probably doesn't need a wiki entry and should go straight to the bug tracker. However, if a specific requirement is undefined, requires code refactoring or the objective of a functionality varies from site to site; then a better understanding is needed before a solution can be executed. Wiki seems ideal to establish resolve before formalizing into a specific issue, at which point, the bug tracker is exquisitely engineered for the task :)</div>
<div><br></div><div>-George</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote></div><div><br></div>-- <br>George Georgalis, (415) 894-2710, <a href="http://www.galis.org/" target="_blank">http://www.galis.org/</a><br>