[Collaboa] time estimates

[Tom Clarke]

On 2/20/06, Waldemar Kornewald <wkornew at gmx.net> wrote:
> Johan Sørensen wrote:
> > I really really don't want to run off starting to implement some
> > plugin/modularity architecture right now and loose any current
> > flexibility I may currently have with the core functionality.
>
> Agreed. I even think that this plugin topic is much too overrated for
> some apps.

Agreed.

> > I can perfectly understand that we all have different needs, but
> > let's face it, Collaboa is at 0.5.5 and we're still shuffling around
> > with the core functionality, let's not get too distracted. And like
>
> Without some definite plan and goals there will always be people who
> want to adapt Collaboa to their personal needs.
>
> > all software, it'll never fit everyone 100%. I'd much rather have
> > flexibility for me as a developer than for my users at this point,
> > harsh words perhaps but I have no interest in trying to abide
> > everyone at this stage, something I'm only now starting to realize.
>
> Could you please tell us what flexibility you need as a developer and
> how would users affect this? I find that statement much too unspecific.
> What is your personal goal?

To Johan: And how does having time-tracking (for example) affect your
flexibility as a developer? If there are coding issues I can help with
to ease this I'm eager to do that.

> My personal goal is to find the *most efficient* method. I don't think
> it's a matter of taste. When someone gets used to something he does not
> want to change it. His argumentation will be related to feelings and he
> will always say "it's a matter of taste", but it's a matter of change.
> IMHO, we are still lacking a very good, simplistic ticket manager that
> does things the right way:
> * make it extremely easy to report bugs and create tickets
> * minimize time spent on ticket management
> * automate as much as possible
> * provide a very clean and simple (not bloated) interface

I heartily agree with these goals.

> If someone doesn't need this then there are a enough existing solutions
> like Bugzilla, Roundup, Trac, Scarab, or whatever you think is best. But
> in the end most of them have the same fields and the same way to manage
> tickets. Some of them are configurable, but none of them really focus on
> usability and innovation.
>
> > As for any forking, sure, if you feel that's needed, that's why it's
> > MIT licensed to begin with...
>
> If so, we should still combine our work in order to save us from
> duplicating code.

I agree, although If I am forced to fork, that will make things
harder. The easiest way to share code is to maintain a time-tracking
and non-timetracking app within the same codebase (just like linux
maintains a PDA and an S390 implementation in the same codebase).

> I looked at many projects (GNOME, KDE, Mozilla, Plone, Trac, ...) and
> compared their way of managing tickets. They are all different. Some
> only have milestones (no version fields) some only have version fields
> (no milestones) and others mix the use of both fields (but in that case
> the observations from my last mail are very often still valid). One
> might conclude that they have different needs, but if you really analyze
> them you will find that their ticket managers are over-flexible such
> that they start using their ticket trackers in the way someone likes the
> most and get used to it without questioning its efficiency.

I do rather agree.. I start from a point of hating bugzilla and it's ilk.

> Tom, I'm not simply into creating a ticket tracker that fits my personal
> needs. I think that current solutions are inherently flawed. Maybe they
> try to serve too different needs. I don't know why they are so
> complicated. I suppose it's because *developers* these products for
> *developers*. Developers have their own understanding of "usability"
> (often equaling "flexibility" or "customizability"). I want a system
> that makes *most* (open-source) projects more efficient because IMHO
> such a product is still missing.
>
> Tom, do you have a real interest in trying something new and throwing
> old concepts over board?

Absolutely. Having parent tickets was my own innovation, I don't think
I've seen it anywhere else. Also, I'm quite proud with my first cut at
replacing the events/timeline screen (checked into trunk). Comments
appreciated.

> It seems to me that you have very specific (and
> uncommon) needs and you are not open to any change. Your only suggestion
> is to make everything customizable such that everyone gets his own
> solution.

There's a balance to be struck. Taking parent tickets as an example,
it would be completely painless to make that optional. Coming up with
a convoluted configuration set up like bugzilla, that's bad - I don't
think this fits into that category.

> I think that we all represent too different interests. Who
> should fork is a question of this project's goals, but too many
> open-source projects spend weeks on searching a good ticket tracker and
> in the end they must agree on a big compromise like Bugzilla (many big
> projects use that beast) or Trac (still far from perfect). Will there
> finally be a solution that concentrates 100% on making ticket management
> as automated+efficient and easy as possible? Maybe I'm alone with that
> thought and maybe it's me who should fork and try out some
> unconventional concepts? I hope that not because otherwise we'll have
> just another product that does it the same way as all other trackers.
> (still milestones, still releases, still severity, still components,
> still complicated to use, still ...)
> I think that we can come up with a method that fits *most* projects (but
> not *all* of them) and at the same time is easier to use than all
> existing solutions.

I think you are exaggerating our differences. So far there are 4 I think:
1) I want time-tracking/billing. If Johan doesn't want that in the
project I have to leave. Simple as that.
2) I disagreed that bugs shouldn't have a milestone. This strikes me
as an exceedingly minor disagreement and one that if it can't be
resolved would be simply solved by adding a configuration field. A
tool can support multiple workstyles without losing coherency.
3) I felt that conflating Versions and Milestones was a bad idea
precisely because I thought it would be confusing to users
4) Parent Tickets. Again this would be pretty painless to make optional

Personally I don't think these  issues make a fundamental
disagreement, as at worst it can be solved with 3 check boxes on
configuration screen (3 I think was resolved already), leaving us to
polish the ticket creation/editing/search/prioritizing interfaces.

The sort of things it would be really bad to have as a configuration
option are say, providing, for example, two entirely different UIs for
a feature. Enabling/disabling features is where configuration could be
really powerful without making the app less coherent. Item 3 above is
one that would be best solved (and I think already has been) by
discussion rather than making it optional. The other 3, are good
candidates for an enable/disable feature.

I sincerely hope we can resolve these issues, as we will all benefit
from more people collaborating on the ticket interface, which I agree
is the central feature around which everything else fits.

-Tom