Out of sight out of mind

[Andrew Edwards via Digitalmars-d]

On 6/15/14, 11:46 AM, Dicebot wrote:
> Big problem with GitHub issues is how simplistic those are. All

Simplistic they are indeed. But how does that detract from the utility 
of the product. As programmers we are may be drawn to complexity, but 
some things need not be complex to be effective.

> categorization is done by labels with no internal differentiation,
> advanced search queries are not possible. Also bugzilla is self-hosted
> solution we have full control about and with GitHub you can only rely on
> what external API exposes.

True, we do not have access to anything but the external API, however I 
don't see that as a limiting factor. When I conduct a search in DITS, I 
effectively search through labels. Of course those labels present 
themselves as data fields/values in some row of a table but they are 
labels none the less. If I want to find issues filed under multiple 
labels, i simply include all labels of interest in my search. The same 
is possible in GitHub, except they are presented right there on the 
screen for immediate access. Want to know how many "bug" request were 
"closed" as "invalid" or "wontfix"? Click on the labels and walla, your 
search is complete. I have had experienced zero issues finding 
information on GitHub, in spite of their overly simplistic interface.

As for internal differentiation of labels... A label is simply a label. 
It has no differentiation or meaning except that applied to it by the 
community. Marking something as

	Product: 	D
	Component: 	DMD
	Version: 	D1 & D2
	Hardware: 	All All

is absolutely no different than creating the labels D1, D2, and All in 
the DMD repo and assigning all three labels to the issue. The only thing 
that gives increase meaning to the labels any label (P1, P2, etc.), is 
the value we, the users, assign to them. As far as I can see the only 
thing GitHub is missing is a way to vote up the value of a label.

> Also consider effort needed for moving all issues from existing database
> and breaking routine workflow of all active dmd/Phobos developers.

Breaking what routine workflow? You can claim that if it's required to 
file an issue in DITS before anything can be done on GitHub but that's 
not the case. You can also claim that if every issue resolved via GitHub 
is explicitly linked to it's originating issue on DITS but that's not 
the case either.

As for the effort to move the issues I'm sure there is a process for 
automatically moving the DITS records to GitHub. And if there isn't, I'm 
not against doing the work myself.

> Personally I don't think this is as much of an issue. Issues don't get
> much attention because there are only few people looking at them (other
> than own issues). Most D users don't have any reason to do so.

You are quite correct, most people will only work on what they want to 
work on. But I think a lot of these issues are ignored because they are 
just not being seen. This move may not motivate any specific person to 
work on any specific bug but it integrates the two processes, and 
automates some of the more often neglected trivialities. It also has the 
added benefit of always visible so it has the positive effect of being a 
constant reminder.