incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: [Issues] [DISCUSS] Can we track Issues Somehow? (was RE: Speaking of JIRA, Where's Ours?)
Date Sun, 14 Aug 2011 03:11:10 GMT
A tracked issue keeps things in one place, it provides a record of open work items and the
actions on it are apparently posted to the list.  So it is much easier to follow the ones
you care about, review them, and so on.  It is also a safer place to post patches, feature
requests, and so on where they can sit until we are actually ready to do something with them.
 The record of progressing action is simply different than tracking wiki pages.

I miss having one.  We're going to need one, it would be good to figure out how to remove
the roadblock involved in worrying how to preserve the OpenOffice.org bugzilla if possible.
 

I also have no idea how many issues we are missing from public contributors because there
is no one to place them.

What I do instead, for specifics to the implementations, is post bugs on LibreOffice and use
their user list.

But we have plenty of work items around the migration here, and if we had an issue tracker,
I would hope that is more inviting for folks taking on something they see as immediately within
their grasp.

 - Dennis

-----Original Message-----
From: Rob Weir [mailto:apache@robweir.com] 
Sent: Saturday, August 13, 2011 18:45
To: ooo-dev@incubator.apache.org
Subject: Re: [Issues] [DISCUSS] Can we track Issues Somehow? (was RE: Speaking of JIRA, Where's
Ours?)

On Sat, Aug 13, 2011 at 1:27 PM, Dennis E. Hamilton
<dennis.hamilton@acm.org> wrote:
> It's been two months since the podling started and we still don't have issue tracking.
>
> 1. We need something for recording and tracking issues now, including ones that are involved
in the migrations we're struggling with.
>

Do we?  I mean, do we need something more than discussing them in
clearly-labeled threads on the mailing list?  Or tracking plans on the
wiki, as we are doing already?

> 2. We don't want to foreclose how we end up finally migrating the OpenOffice.org bug
tracker and all of the history that represents.
>
> I don't know enough to see how to have (1) and (2) both.  Can we choose one quickly for
transitional use, and then merge the OO.o bugs with it or merge it with the OO.o bugs, whichever
works?
>
> It looks like three choices have been proposed:
>
>  1. Apache JIRA
>  2. Apache bug-tracker
>  3. Google Code issue tracker (available on Apache Extras)
>

I started tracking some items on the wiki, as a short term approach.
Since there appears to be a great deal of enthusiasm for using the
wiki, how about start that way?  If we're dealing with a dozen or 2
issues or fewer, then setting up a JIRA or BZ issue is overkill.
Remember, we're already tracking planning activities related to the
migration on the wiki.  It isn't clear that trying to tease action
items out of the plans on the wiki and then placing them in JIRA does
anything for us.

Also, we should avoid the seductive illusion that activity is a
substitute for progress.  Having volunteers move forward on the code
check-ins and on the real Bugzilla migration would be progress.
Churning on issue tracking would not.

> I'm all for ease-of-use.  How can we have a working issue tracker off of the critical
path around migrating the OpenOffice.org bug tracker without getting in the way of that more
complex effort?  Do we have to choose one for the migrated bug tracking now or can we resolve
that later?
>

Easiest way to avoid the more complex effort is to use the simplest
tool that accomplishes the task.  The simplest tool right now is the
mailing list.  Wiki is 2nd.

>  - Dennis
>
> -----Original Message-----
> From: Greg Stein [mailto:gstein@gmail.com]
> Sent: Thursday, June 30, 2011 16:05
> To: ooo-dev@incubator.apache.org
> Subject: Re: Speaking of JIRA, Where's Ours?
>
> On Thu, Jun 30, 2011 at 12:54, Rob Weir <apache@robweir.com> wrote:
>> On Thu, Jun 30, 2011 at 12:12 PM, Alexandro Colorado <jza@openoffice.org> wrote:
> [ ... ]
>>>
>>> I can argually say that both suck, the issue tracker that I have seen
>>> easiest is the one provided by google code.
>>>
>>> The problem with that tracker is that I am not sure is doable for larger
>>> projects.
>
> The Chromium project uses Google Code's tracker[1]. They're over
> 88,000 bugs now and going.
>
>>> The biggest hump of using an issue tracker is locating the right people
>>> (subcomponent) to get the issue to, or asigning a developer to it. whcih
>>> most times is not aparent. The previous OOo (Collabnet) supported templates
>>> which fill out your issue tracker in order to submit the issues faster.
>>> However I found not many people really used it.
>>>
>>
>> There are two audiences (at least) for the tracker:
>>
>> 1) Project members, who know their way around, know the sub components, etc.
>>
>> 2) Users, or other who submit a defect report rarely. They need an
>> easy way to enter a bug report and check its status later.
>
> Totally agree. And that was the basis of my design for the Google Code
> tracker. I wanted it real easy for the users to submit a bug, and
> possibly attach stuff. They only need a short description, and then
> details. Users know *nothing* about subcomponents, assignees,
> milestones, whatever. The developers would then triage the new bugs
> and apply the correct tags.
>
> Jason Robbins built the tracker using those key principles, and I
> think it turned out very well. Of course, I'm biased. But still :-)
>
> If we wanted to use it, then we could fire up a project on
> apache-extras.org and use it. We can use its API to import all the old
> bugs.
>
>>...
>> And what if we didn't assign developers at all?  What if instead we
>> had project volunteers claim what issues they want to work on and
>> self-assign them?
>
> I'd prefer this approach. It is generally best to view the bugs as
> owned by the community. That you don't have "one developer" assigned
> to a component. And that anybody can grab a bug and start working.
>
>>...
>
> Cheers,
> -g
>
> [1] http://code.google.com/p/chromium/issues/list
>
>


Mime
View raw message