Re: [CLEANUP RFC] The list of lists

* Sawyer X <xsaw...@gmail.com> [2014-10-19T12:53:49]
> Since many replies started from this email, I'll reply to Craig's points,> hoping it will cover the rest of the replies too.

An excellent choice!

> Agreed. However, your sentence seems to me as if it's implying Perl> maintenance is one layer of centralized work where you either have all of> it or none. However, as far as I understand, it's as decentralized as any> other project, where some people know some areas more than others.> > This means some people care about breakage in their subsystems, others in> other subsystems. Some people might have an overall view in which they want> to know of all subsystems breakage.> > This is where a split view is ideal. Unless every single person on the list> needs to know about every single subsystem that breaks, having a list with> everything is simply unnecessary.

How would this work in practice?  Would you have a set of tags on each ticket,
and then only users subscribed to a ticket's tags would get its updates?

Presumably posts directly to the list would still go to everyone.  Smokes would
be on their own separate list?

I feel like "a split per subsystem" is a big change from "split bugs and smoke
reports into two lists," which seemed more the gist of your previous message.
I may have misunderstood this message or that one, though.

> > Bug reports and patches need on-list discussion.  I can't really think> > of a use case for being involved in maintaining Perl but filtering> > those things out.> > But does everyone need to view every single ticket discussion?

No, but the options are roughly "everybody gets the mail by default" or "you
have to know how to opt in."  (That is putting aside the idea of someone
building a tag-based system.)

If everyone gets all the mail, it's possible (and happens /quite/ often imho)
that two people are discussing a ticket when suddenly a third or fourth person
joins in with an important piece of information that would've never been
available if the ticket went from "new" to "taken" by the first person.

After all, how would that work here:

> A ticket system dictates that you view the conversation if:> * You opened the ticket.> * You were assigned the ticket.> * You were added as a watcher.> * You registered yourself to get updated.

An *extremely* important point here is that we don't "assign" tickets to
workers in almost any case.  It happens quite rarely.  Tickets get worked on by
the first witness to the ticket who ... well, the first one who works on it.
If a ticket was assigned, this would be a different matter, because there would
be some expectation, I think, that the assigner knew the assignee would get it
done on their own.  It wouldn't be a team effort.  But that's what we have
here.

If A files a ticket, how is it noticed?  Who works on it?  How does any third
party notice that the fix will break their almost-ready-to-merge branch?

I guess what I mean is this:

You are describing a different way of organizing the mails we send, but I think
it would require a substantially different workflow, which you have not
described.

> > These only go to p5p if the smoke set-up has the ccp5p_onfail> > configuration option explicitly chosen.> > Off-topic question: why would someone turn this on?

I wondered the same thing.

-- 
rjbs