On 18/03/13 09:26, Peter Koželj wrote:
On 18 March 2013 08:53, Branko Čibej <[email protected]> wrote:
On 18.03.2013 06:56, Peter Koželj wrote:
Unfortunately, for the better or for the worse, this is obviously not the
Apache way.
Eh? There is no "Apache Way" when it comes to managing projects, other
than the premise that recoghition is gained by merit, not by decree, and
that no-one has the power to dictate how a project will be run -- such
decisions should, in general, be reached by consensus.
Ok, good to hear that.
But I am always opened to alternatives. Obviously there are dozens of
Apache projects with large communities
that seem to manage without much backing from their ticket systems just
fine. I am curious...
At the very minimum, we do need to move the discussions from Tickets to
mailing lists as it's a Apache requirement,
if I understand correctly.
You misunderstand. Neither Greg nor I ever said anything about
requirements, but we do have opinions about efficiency and
inclusiveness. Every developer is required to be subscribed to the
development list. Major decisions e.g, votes, happen on the list.
Therefore, by keeping discussions on the mailing list, rather than in a
completely disconnected issue tracking system, you'll reach more
interested parties. Moreover, it's /harder/ to keep track of comments on
the tickets than it is to keep track of discussions on the list.
That "harder" is a bit subjective. For someone who is interested in
everything that has to do with project, I agree.
For someone who is only interested in only a feature or two it is probably
easier.
There is definitely a tradeoff here between the noise of lots of issues
being discussed and the ability to focus on specific issues. However, we
may have problems with the discoverability of these discussions if we
were to stick only to tickets. Moving discussions from the issue tracker
to the mailing list should benefit overall inclusiveness on the
assumption that everyone is on the mailing list and that interested
parties are more likely to be looking there.
Personally I think the problem I am seeing is that we kind of choose to
discuss every little detail to death instead of
just doing it. The mechanics we choose (tickets vs. ML) is of much lesser
concern to me.
Yes, this is something that seems to crop up a fair bit. I would hope
that discussion being on the dev list would make it quicker for people
to call out such behaviour.
There is nothing wrong with using issue trackers to track bugs, or even
tasks. I myself have used issue trackers as a project management tool --
but in different circumstances.
Let me try to give a concrete example: This community has decided to
introduce "Bloodhound enhancement proposals" as a formalized procedure
for defining and accepting feature definitions. Fine. But, why then,
once the feature has been designed and documented, take the extra step
of breaking it down into separate tasks and creating tracker entries for
those -- instead of just writing code? The exact same level of oversight
can be achieved, with much less context switching and overhead, simply
by writing informative log messages -- which are, IMO, a lot more useful
to someone who tries to understand the reasoning behind a certain piece
of code from commit history.
I can't deny that last bit of logic as it is a bit self referential.
Yes, we want to see good log messages to enable scrutiny through the
log. However, we should also benefit through linking commits to a ticket
which is an easier way to put a change in context. A commit message is
often going to be more about what happened than why.
Cheers,
Gary
