Hey all, I've noticed, for a while, that bloodhound-dev is filled with more ticket activity than commit activity. This doesn't seem right.
Using tickets to plan changes is more of a Review-Than-Commit approach, and is definitely slower for development. This project was set up as Commit-Then-Review, but I think it has fallen into a "let's use our BH install and file tickets for everything" mode. As a result, development appears to be *much* slower than it should otherwise be. When filing a ticket, I would encourage everybody to stop and reconsider. If you can perform a commit, then do that instead. Others can review the commit, rather than the ticket. If you are working on some code, and are skipping some work, then just drop in a comment about the future-needed work. In the Subversion project, we've found that marking these comments with ### makes them easy to spot/find (no code/prose looks like that, so they stand out). By placing these "to-do" markers into the code while you're working there, and committing, it means you don't have to change contexts to go and file a future work ticket. If you want to discuss something, then consider just placing it onto the dev@ list. Most people want to interact on the *list* ... not through comments on tickets. By filing a ticket, for something intended for discussion, then you're actually working against yourself. The broadest (and easiest) discussion forum is here on dev@. I would recommend filing tickets *only* for bugs. Please... let's get back to Commit-Then-Review. More commits. Less tickets. Thx, -g
