I was testing, I'll not oppose to revert back, re-added most of the removed labels, some comments:
liked the idea to differentiate between enhanceemnts/tweaks
There is a noticeable difference, I like it too, but as you can see on this thread, is somewhat difficult for some people to understand or differentiate, lacking label
I can share my experience filling the first serie of bugs, it was a little hard for me to choose bug types, severities, there was an overlap with feature, tweak and enhancement. Very confusing.
Also, I don't know the "severity", I just select one because, is somewhat required, but.. as mentioned, this is relative to the use you do to the editor... something major for me, can be very minor for you.. don't know how to solve it..
I suggest we start filling bugs, once there is some content to classify
, we will eventually see things to improve, and then, we can start thinking on how to better tag content. Categories already provide a very good classification, giving location which is very important, because reduce the scope of the issues a lot. I started to think, that this software does not have a big amount of bugs, may have some of these complicated to explain. But I don't think there is 1000 bugs, I can estimate something in the lines of 500~ including features request, will be very easy to navigate and read by clicking very few tags: a category and a type. Is not that you will click a tag and see 200 bugs, maybe 50.. depending of the category, easy to scan with the eyes. (Maybe I'm wrong, that's just my imagination)
Well, my suggestion is, if we don't fill bugs, this will not work.
Allow some mess up at the beginning, be kind, try to be open minded
, this software is used in many ways by people of different cultures and backgrounds, try to encourage people to explain further, if you think is required, or is not clear, people will likely help to report properly. ( as seen in #13 )
Maybe we can start by importing bugs from userecho and forums. The big difference here is that we can contribute by moderating everything.
Even further, an argument could be made that "Commands" and "API" should also be merged into just "API". What is the use case for having a different tag for "Commands" vs "API" ?
API: classes and functions that the editor provides: http://www.sublimetext.com/docs/3/api_reference.html
Comands: set of user defined functions(there is some shipped commmands too, take a look to the Default package) that use 1 or more API calls to do X(almost any) tasks: http://docs.sublimetext.info/en/latest/ ... ility.html
Commands are the basic method for interacting with Sublime Text. Key bindings, menu items, toolbar buttons and macros all work through the command system
A package defines commands, that use the API to customize the editor.
About crashes, I think these should be reported in forums, and maybe tracked in github. I say reported in forums, because crashes can cause real problems. Jon seems to monitor these problems seriously.
I will keep an eye into this project and thread, trying to fill bugs. Don't wait for my approval, this is a community project, don't forget, If you see there is consensus between the participants, move with attitude!