Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of apache@robweir.com designates
 69.89.21.8 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <003901cc5a2f$d21bc5e0$765351a0$@acm.org>
References: <005301cc59de$4693e0d0$d3bba270$@acm.org>
	<CAP-ksoiqzeTL_GOUmZDyXCWZfQdedsX5RY_5Fw61VFEh2K9SYA@mail.gmail.com>
	<003901cc5a2f$d21bc5e0$765351a0$@acm.org>
Date: Sun, 14 Aug 2011 09:03:29 -0400
Message-ID: 
 <CAP-ksohBSzE3LdvZWQACCZL6t5fxpXpWCWumyE9RygrEg4X9ew@mail.gmail.com>
Subject: Re: [Issues] [DISCUSS] Can we track Issues Somehow? (was RE: Speaking
 of JIRA, Where's Ours?)
From: Rob Weir <apache@robweir.com>
To: ooo-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Aug 13, 2011 at 11:11 PM, Dennis E. Hamilton
<dennis.hamilton@acm.org> wrote:
> A tracked issue keeps things in one place, it provides a record of open w=
ork items and the actions on it are apparently posted to the list. =C2=A0So=
 it is much easier to follow the ones you care about, review them, and so o=
n. =C2=A0It 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 the=
m. =C2=A0The record of progressing action is simply different than tracking=
 wiki pages.
>

You were originally asking about issues related to migration.  I don't
expect that will include many patches, feature requests (at least not
outside of the list discussions).

If you have other issues of a more general nature, why not just stick
them in the existing Bugzilla?  Nothing there will be lost.  It might
be locked to updates for a day or two during the actual migration.
But up to that point all issues entered there are slated to be
eventually migrated to an Apache host.

> I miss having one. =C2=A0We're going to need one, it would be good to fig=
ure out how to remove the roadblock involved in worrying how to preserve th=
e OpenOffice.org bugzilla if possible.
>

That part's easy, at least conceptually.  Someone steps up and volunteers.

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

Don't you think the public would be more familiar with the OOo
Bugzilla tracker that has been around for years than any new,
temporary issue tracker that we might set up?  If you want, we could
post a link to the OOo BZ from our home page, for the benefit of those
who are newly involved with the project.  Post-migration, the URL
should be the same.

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

So you can do the same for OpenOffice, right?  Or is there some
problem I'm not seeing with this?

> 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 s=
omething they see as immediately within their grasp.
>

I still think for migration-related issues, the mailing list and the
wiki are the best places.  Adding a third place to store such
information will just scatter the information more than concentrate
it.  If we had used an issue tracker consistently from the start it
might have been different.  But we didn't.

> =C2=A0- 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: Spe=
aking 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 i=
ssue tracking.
>>
>> 1. We need something for recording and tracking issues now, including on=
es that are involved in the migrations we're struggling with.
>>
>
> Do we? =C2=A0I mean, do we need something more than discussing them in
> clearly-labeled threads on the mailing list? =C2=A0Or tracking plans on t=
he
> wiki, as we are doing already?
>
>> 2. We don't want to foreclose how we end up finally migrating the OpenOf=
fice.org bug tracker and all of the history that represents.
>>
>> I don't know enough to see how to have (1) and (2) both. =C2=A0Can we ch=
oose 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:
>>
>> =C2=A01. Apache JIRA
>> =C2=A02. Apache bug-tracker
>> =C2=A03. 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? =C2=A0If 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. =C2=A0It 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. =C2=A0Having 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. =C2=A0How can we have a working issue tracker o=
ff of the critical path around migrating the OpenOffice.org bug tracker wit=
hout getting in the way of that more complex effort? =C2=A0Do we have to ch=
oose 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. =C2=A0The simplest tool right now is the
> mailing list. =C2=A0Wiki is 2nd.
>
>> =C2=A0- 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.or=
g> 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 larg=
er
>>>> 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 peopl=
e
>>>> (subcomponent) to get the issue to, or asigning a developer to it. whc=
ih
>>>> most times is not aparent. The previous OOo (Collabnet) supported temp=
lates
>>>> 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? =C2=A0What if instead w=
e
>>> 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
>>
>>
>
>