[Collaboa] goals?

[Tom Clarke]

On 2/16/06, Waldemar Kornewald <wkornew at gmx.net> wrote:
> Tom Clarke wrote:
> > I'm not particularly tied to any particular names although Severity is
> > often orthoganal to priority (at least in other systems I've used). It
> > might be nice to put these names in a config as different people have
> > different requirements. In general I like the idea of being able to
> > disable unused portions to keep the UI as streamlined as possible for
> > any given task.
>
> Would be fine with me, too.
> But: could you please explain to me what the difference and use for both is?
> Priority: developer's priority
> Severity: user's priority
> Well, what about not allowing users to give any estimates? The
> developers can assign a priority after a new ticket has been created.
> Users can't give us much valuable information about priority/severity.

That's true... and in actuality the information is probably mostly
used in a triage scenario where someone else actually allocates the
work into upcoming releases. I could probably live without those
fields at all I think, it's probably just too much bugzilla usage that
makes me think I care :-)

> > One thing, what do you mean 'removing Milestone'? You don't like
> > having tickets organized into milestones?
>
> Oh, no. I just wanted to rename Milestones into Roadmap and remove the
> "Milestone" field from tickets. Version (was: Release) should take over
> the function of milestones. What milestone+version are used for:
> Milestone: when it should be finished
> Version: when it was discovered
> Well, for tasks/wishes it does not make sense to specify a version and
> for bugs it is sufficient to know when a bug was found. Though, I can
> imagine that specifying in which version a bug should be fixed could be
> useful, I think that a bug's priority already tells enough about when it
> should be fixed. Blockers must be fixed "yesterday", critical bugs as
> soon as possible and so on...the team can decide on this.

I think I get the idea, though I'm not sure I follw why miletones get
removed from tickets (unless you mean by way of renaming it to
roadmap). I think I prefer the name 'Milestone' over 'Roadmap' though.

As far as the version it was reported in, it's actually not useful to
me though I could see a situation where there is more than one version
in the wild where it could be useful.

> >> For example, in the ticket details view all fields should be editable
> >> directly at the top instead of showing just text and allowing to edit at
> >> the bottom. If you don't have enough permissions for editing you will
> >> continue to see non-editable text.
> >
> > I like it.. have you seen the ajax implementation of the comment
> > editing in trunk?  This could be seen as a first attempt to do just
> > that.
>
> No, I'll have a look ASAP (but might be next week since at Haiku there
> is currently very much going).
>
> >> BTW, why are there so many vendor components in SVN? ActiveRecord,
> >> ActionMailer, etc.. Are they not part of the default distribution? You
> >> see, I'm rather new to Rails. ;)
> >
> > I believe they are stored as 'svn:externals'. That is, rather like a
> > symbolic link. The reason is because collaboa is tested against a
> > particular version of rails, and it's simpler if it's included in this
> > way.
>
> Okay. But for incorporating Collaboa into different projects (CMS, for
> example) it could be nice to have it working with the most recent
> version. Also this gives the wrong impression of a heavyweight product.
> Is it really so problematic to keep it up to date?
> Which version are you using?

For a while before rails 1.0 it was using a particular version of edge
rails. Right now we're 1.0 which is the current stable. I think
everyone is in favour of tracking stable releases pretty closely.
Before 1.0 rails was changing a bit, perhaps we'll get an idea in
rails 1.1 whether upgrades will be painless.

-Tom