You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucy.apache.org by Marvin Humphrey <ma...@rectangular.com> on 2010/07/24 19:16:35 UTC
lucy-issues list
Greets,
Lucene sub-projects traditionally have all JIRA notifications sent to the dev
list. However, not all Apache projects follow this convention -- some have
dedicated "issues" lists. Although it was not in our proposal, I think Lucy
should consider requesting such a list.
First, JIRA is noisy. There are too many messages, and though I generally try
to make sure that even the messages where I attach files contain meaningful
comments, most people on other lists (e.g. dev@lucene.a.o) do not, resulting
in voluminous notification-only traffic to the dev list. Furthermore, lots of
people make trivial edits to their JIRA comments, resulting in heinous
pseuedo-diff messages containing the entire "before" and "after", no matter
how small the change.
Second, meandering conversations in JIRA become commonplace when cc'd to the
dev list. This is bad because posters are not able to change the subject line,
so the archives become harder to peruse and search. Important conversations
get buried in giganto JIRA threads -- e.g.
<https://issues.apache.org/jira/browse/LUCENE-1458>, where per-segment search
was hashed out. Browsing conversations via Apache's enormous JIRA installation
is a pain -- issues.apache.org is overloaded and slow, and the JIRA search
interface is not to everyone's liking. There are numerous mail archiving
services with interfaces to suit a variety of tastes (Markmail, Nabble, etc.)
-- these all function better when fed traditional email list posts than JIRA
notifications.
My preference is to limit exchanges in JIRA to technical issues of applying
patches. All consensus building and discussion should take place on the dev
list, as Karl Fogel advocates:
http://producingoss.com/en/bug-tracker-usage.html
No Conversations in the Bug Tracker
In any project that's making active use of its bug tracker, there is
always a danger of the tracker turning into a discussion forum itself,
even though the mailing lists would really be better. Usually it starts
off innocently enough: someone annotates an issue with, say, a proposed
solution, or a partial patch. Someone else sees this, realizes there are
problems with the solution, and attaches another annotation pointing out
the problems. The first person responds, again by appending to the
issue...and so it goes.
...
There isn't one right answer, but there is a general principle: if you're
just adding data to an issue, then do it in the tracker, but if you're
starting a conversation, then do it on the mailing list.
To this end, I propose the following:
* Request a lucy-issues@incubator.a.o list.
* Change all JIRA notifications to go to the lucy-issues list.
* Set followups on lucy-issues to go to lucy-dev.
Marvin Humphrey
Re: lucy-issues list
Posted by Michael McCandless <lu...@mikemccandless.com>.
I fear it's only human/dev nature to engage in meandering conversations no matter the channel, so I don't know whether a separate issues list will "work", but I agree it's worth a shot!
Mike
On Jul 25, 2010, at 1:36 AM, "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov> wrote:
> +1, sounds good to me to have the additional lucy-issues@ lists per the specification you mention below, Marvin...
>
> Cheers,
> Chris
>
>
>
> On 7/24/10 10:16 AM, "Marvin Humphrey" <ma...@rectangular.com> wrote:
>
> Greets,
>
> Lucene sub-projects traditionally have all JIRA notifications sent to the dev
> list. However, not all Apache projects follow this convention -- some have
> dedicated "issues" lists. Although it was not in our proposal, I think Lucy
> should consider requesting such a list.
>
> First, JIRA is noisy. There are too many messages, and though I generally try
> to make sure that even the messages where I attach files contain meaningful
> comments, most people on other lists (e.g. dev@lucene.a.o) do not, resulting
> in voluminous notification-only traffic to the dev list. Furthermore, lots of
> people make trivial edits to their JIRA comments, resulting in heinous
> pseuedo-diff messages containing the entire "before" and "after", no matter
> how small the change.
>
> Second, meandering conversations in JIRA become commonplace when cc'd to the
> dev list. This is bad because posters are not able to change the subject line,
> so the archives become harder to peruse and search. Important conversations
> get buried in giganto JIRA threads -- e.g.
> <https://issues.apache.org/jira/browse/LUCENE-1458>, where per-segment search
> was hashed out. Browsing conversations via Apache's enormous JIRA installation
> is a pain -- issues.apache.org is overloaded and slow, and the JIRA search
> interface is not to everyone's liking. There are numerous mail archiving
> services with interfaces to suit a variety of tastes (Markmail, Nabble, etc.)
> -- these all function better when fed traditional email list posts than JIRA
> notifications.
>
> My preference is to limit exchanges in JIRA to technical issues of applying
> patches. All consensus building and discussion should take place on the dev
> list, as Karl Fogel advocates:
>
> http://producingoss.com/en/bug-tracker-usage.html
>
> No Conversations in the Bug Tracker
>
> In any project that's making active use of its bug tracker, there is
> always a danger of the tracker turning into a discussion forum itself,
> even though the mailing lists would really be better. Usually it starts
> off innocently enough: someone annotates an issue with, say, a proposed
> solution, or a partial patch. Someone else sees this, realizes there are
> problems with the solution, and attaches another annotation pointing out
> the problems. The first person responds, again by appending to the
> issue...and so it goes.
>
> ...
>
> There isn't one right answer, but there is a general principle: if you're
> just adding data to an issue, then do it in the tracker, but if you're
> starting a conversation, then do it on the mailing list.
>
> To this end, I propose the following:
>
> * Request a lucy-issues@incubator.a.o list.
> * Change all JIRA notifications to go to the lucy-issues list.
> * Set followups on lucy-issues to go to lucy-dev.
>
> Marvin Humphrey
>
>
>
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: Chris.Mattmann@jpl.nasa.gov
> WWW: http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
Re: lucy-issues list
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
+1, sounds good to me to have the additional lucy-issues@ lists per the specification you mention below, Marvin...
Cheers,
Chris
On 7/24/10 10:16 AM, "Marvin Humphrey" <ma...@rectangular.com> wrote:
Greets,
Lucene sub-projects traditionally have all JIRA notifications sent to the dev
list. However, not all Apache projects follow this convention -- some have
dedicated "issues" lists. Although it was not in our proposal, I think Lucy
should consider requesting such a list.
First, JIRA is noisy. There are too many messages, and though I generally try
to make sure that even the messages where I attach files contain meaningful
comments, most people on other lists (e.g. dev@lucene.a.o) do not, resulting
in voluminous notification-only traffic to the dev list. Furthermore, lots of
people make trivial edits to their JIRA comments, resulting in heinous
pseuedo-diff messages containing the entire "before" and "after", no matter
how small the change.
Second, meandering conversations in JIRA become commonplace when cc'd to the
dev list. This is bad because posters are not able to change the subject line,
so the archives become harder to peruse and search. Important conversations
get buried in giganto JIRA threads -- e.g.
<https://issues.apache.org/jira/browse/LUCENE-1458>, where per-segment search
was hashed out. Browsing conversations via Apache's enormous JIRA installation
is a pain -- issues.apache.org is overloaded and slow, and the JIRA search
interface is not to everyone's liking. There are numerous mail archiving
services with interfaces to suit a variety of tastes (Markmail, Nabble, etc.)
-- these all function better when fed traditional email list posts than JIRA
notifications.
My preference is to limit exchanges in JIRA to technical issues of applying
patches. All consensus building and discussion should take place on the dev
list, as Karl Fogel advocates:
http://producingoss.com/en/bug-tracker-usage.html
No Conversations in the Bug Tracker
In any project that's making active use of its bug tracker, there is
always a danger of the tracker turning into a discussion forum itself,
even though the mailing lists would really be better. Usually it starts
off innocently enough: someone annotates an issue with, say, a proposed
solution, or a partial patch. Someone else sees this, realizes there are
problems with the solution, and attaches another annotation pointing out
the problems. The first person responds, again by appending to the
issue...and so it goes.
...
There isn't one right answer, but there is a general principle: if you're
just adding data to an issue, then do it in the tracker, but if you're
starting a conversation, then do it on the mailing list.
To this end, I propose the following:
* Request a lucy-issues@incubator.a.o list.
* Change all JIRA notifications to go to the lucy-issues list.
* Set followups on lucy-issues to go to lucy-dev.
Marvin Humphrey
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++