Skip to end of metadata
Go to start of metadata

<ul>
<li>PHP support in latest code formatter plugins</li>
<li>Code coverage for PHPUnit in Bamboo</li>
<li>Mechanism/process for resolving issues instead of leaving them open indefinitely
<ul>
<li>All issues will be auto-assigned to component leads (this is already the case)</li>
<li>The component leads will have some number of days (30, for example) to 'resolve' the issue</li>
<li>All issues can be resolved as 'not an issue', 'duplicate', 'fixed', and <strong>'postponed'</strong>. Postponed indicates that the issue has been reviewed by the component lead, but s/he won't fix it within the time period for resolving (it's too big in scope, it requires discussion and/or decision making, lead is going on vacation, etc.)</li>
<li>The issue remains assigned to the issue. A contributor should approach the lead if s/he would like to fix it. The lead will ensure that the proposed fix is appropriate. Issue is reassigned to the contributor and reopened pending a fix. Lead may also solicit help on IRC, mailing list, etc.</li>
<li>When the formerly postponed issue gets fixed, it is closed as 'fixed'. (Duh!)</li>
<li>Notifications will remind the component leads when an issue comes in, 5 days before the review period, and at the end of the review period. Notifications will stop when issue is reserved.</li>
<li>A filter will be made available listing all open bugs assigned to the current user and the number of days they've been open. If possible the report will 'stoplight' the issues based on days open. Green is still young, Yellow is getting old, Red is very old. Wil to find out if coloring or some other way to highlight issues based on date is available.</li>
</ul>
</li>
</ul>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Dec 09, 2008

    <p>Actualy the issue tracker is also used to track new features and improvements.<br />
    Several people are also using it to track work progress (subtasks / tasks) for the next 2 major releases</p>

    <p>So what you said should only be true for bugs not for improvements and new features.</p>

    <p>Also another thing is that a bug may only be solved by breaking BC, which means it can only be solved within the next minor/major release. Actually there is no way to handle this except setting postponed.</p>

    <p>And some bugs are not bugs but more improvements. The actual implementation does simply not handle this and have to be reworked. Also this is more a solution for the next minor release but there is no way to note this except setting postponed.</p>

    <p>What I think is that there</p>
    <ul>
    <li>should be a way for component leads to set a issue for being free for public bugfixing.</li>
    <li>and there should be a way to prevent that bugs are fixed public because we know it's difficult and breaks implementation. This would force the lead to add a note with the description why it is set to un-public.</li>
    <li>It should also be clear that when someone fixes a issue he must also add related unittests. It can not be that the component lead must do this as it's actually the case in many issues.</li>
    </ul>

    <p>Greetings<br />
    Thomas, I18N Team Leader</p>