Done. A little different now, though. * 73 Cleanup / Enhancement <https://github.com/scikit-learn/scikit-learn/issues?labels=Cleanup+%2F+Enhancement&page=1&sort=updated&state=open>
* 30 Crash / Bug <https://github.com/scikit-learn/scikit-learn/issues?labels=Crash+%2F+Bug&page=1&sort=updated&state=open> * 9 Documentation <https://github.com/scikit-learn/scikit-learn/issues?labels=Documentation&page=1&sort=updated&state=open> * 17 Easy <https://github.com/scikit-learn/scikit-learn/issues?labels=Easy&page=1&sort=updated&state=open> * 11 Moderate <https://github.com/scikit-learn/scikit-learn/issues?labels=Moderate&page=1&sort=updated&state=open> * 80 New Feature <https://github.com/scikit-learn/scikit-learn/issues?labels=New+Feature&page=1&sort=updated&state=open>I found it hard to distinguish Cleanup and API stuff, so I just merge the two. Now all issues / PRs have either a Crash, Cleanup, Documentation or New Feature tag.
That gives a nice traffic light feel to the importance of the issue. Apart from "Easy" for newcommers, I also introduced a "Moderate" for non-core-devs. The idea was to have the "easy" really easy. If I misjudged anywhere, feel free to retag. I hope this benefits the development process. Docs coming soon. Cheers, Andy On 09/02/2012 02:10 PM, Andreas Mueller wrote:
Hey everybody. I noticed in the last couple of month that the way we use tags on the issues makes them pretty useless. At least they are useless to me and I am working on the issues quite often. The only thing that I found helpful is the "easy fix" tag, but not everything that was "easy fix" really was one. I suggest to remove all tags as they are currently used and establish a new system, with the following tags: - bug: something that clearly shouldn't happen. There are some of those hidden on the issue list beneath 100 feature requests. - easy fix: something that a newcomer could tackle. - cleanup/enh: issues where the code is ugly and/or slow - feature request: something that is not there, but you want to have. It's absent is not a bug though. - api: inconsistent api problems - documentation: places where the documentation is wrong or below standards. This directly gives them some sort of hierarchy. The bugs are clearly more important to fix than the feature requests. At the moment, when I am looking for bugs to fix, or see if a bug is known, I have to dig through 200 issues. WDYT? btw: I volunteer to retag all issues. Andy ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Scikit-learn-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ Scikit-learn-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
