bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Commits vs Tickets
Date Wed, 06 Mar 2013 07:57:02 GMT
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.


View raw message