I'll just post this here for discussion:What about renaming the repo to "SublimeText/Issues"? Because "BugTracking" seems to imply that this is a plugin to track bugs within Sublime Text or similar whereas "Issues" is more straight forward. Plus, with the "SublimeText" org in front of it it translates to "Sublime Text Issues".

On this forum, I have seen posts of 3 types:1. (50%) "How do I do this" - someone is asking how to do or achieve something, turn a certain feature off, etc. Many of these posts arise because of the unorganized state of the documentation. (For example if you search for something on Google you often get a documentation page for SublimeText v1 which does not indicate that it is from an older version). Also the documentation pages do not have any kind of tree-like navigation on them so if you find one documentation page from Google you are lost as to how to find or get a sense of the rest of the documentation.

2. (40%) Feature Requests - a person has read the documentation and understood the basics of configuring Sublime. They have tried and feel that what they want cannot be achieved with the existing feature set / plugin API. They write about what they have already tried and ask the developer to add something more in a future build (for example a new API method). Half of these get replied to with a solution that it is indeed possible to achieve with existing plugin API - a moderator should then immediately close these. The other half of these are genuine Feature Requests that are unsolvable via the current plugin API that should remain open for the developer to look at.

3. (10%) Bug Reports - a genuine inconsistency bug of something that is wrong in Sublime.

Type 1 - the forum should be used for these questionsType 2 and 3 - I believe should be handled by the system suggested here, since Userecho interface is inadequate and something like Trac interface would be much more suited to handle.

Suggest adding a label to indicate the the issue also affects ST2, since the tracker is primarily for ST3 issues and FR's.

My preference would be to go further and generalise the tracker to Sublime Text with labels to indicate ST2 and ST3. I know this was discussed a bit already, but this allows issues to be flagged as ST2 only, ST3 only or both, which might be useful info for Jon.

Who's going to be moderating this? In order for it to be useful the signal-noise ratio needs to be kept right and I think if we can do this with github there should be a policy for removing / closing out issues.

Can you back this data up?Again, I see major problems with feature requests in this repo

1.) There are too many. It will clutter the repo.2.) Who is going to decide if the feature should be in ST or if it is a feature worth having? There will be endless discussions about feature x, if it is good, what it should entail etc. Bugs have clear boundaries, it's easier to say "This is a bug"

I'd say let's keep the repo for reporting issues that exist now in ST. Bugs, inconsistencies, things that should be there because in another part. Not completely new features

@qgates: Everyone in the SublimeText org should have admin rights for this repo. A policy for closing issues is a good idea.

@Narretz: That's what labels are for. If Jon doesn't care about feature requests because he is too busy fixing other bugs, that's fine, he can just select the "T: bug" label and all these other things will be hidden. You can't OR labels so you can't see bugs and enhancements at the same time but it still works and you can switch between them relatively quickly.Regarding point 2, I have no idea. We can probably only set a severity to the issue, Jon (or any other possible developer) is the only one who can say "I'll implement this" or "I won't". But we can tell people workarounds for issues so it might still help a little. For the rest of the time most of this issue will likely remain open.