Commits vs Tickets

[Greg Stein <gs...@gmail.com>]

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

Re: Commits vs Tickets

[Joachim Dreimann <jo...@wandisco.com>]

On 6 March 2013 08:15, Branko Čibej <br...@wandisco.com> wrote:

> On 06.03.2013 08:57, Greg Stein wrote:
> > 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.
> >
>

As for the below:

> > 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.
>

There's a caveat to this in our case: We can't browse the repository from
Bloodhound itself.

The ticket for this has been open since last July, a solution had been
agreed 6 months ago:
https://issues.apache.org/jira/browse/INFRA-5064

I did chase this up recently without success.

- Joe


> >
> > 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.
>
> We've had this discussion before, and for a short time the situation was
> better. ... but apparently not for long.
>
> I absolutely agree with Greg. There's something wrong with the fact that
> there are several hundred tickets open, many of them seem to be
> "implementation instructions" for designs in the wiki -- which clearly
> should've resulted in code, not more tickets. :)
>
> -- Brane
>
> --
> Branko Čibej
> Director of Subversion | WANdisco | www.wandisco.com
>
>


-- 
Joe Dreimann
UX Designer | WANdisco <http://www.wandisco.com/>

Re: Commits vs Tickets

[Branko Čibej <br...@wandisco.com>]

On 06.03.2013 08:57, Greg Stein wrote:
> 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.

We've had this discussion before, and for a short time the situation was
better. ... but apparently not for long.

I absolutely agree with Greg. There's something wrong with the fact that
there are several hundred tickets open, many of them seem to be
"implementation instructions" for designs in the wiki -- which clearly
should've resulted in code, not more tickets. :)

-- Brane

-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com