Proposal: Mailing List Cull
alex.buckley at oracle.com
Wed Mar 13 19:28:26 UTC 2019
Mailing lists are just one kind of artifact associated with a Project. I
suggest that what you're really imagining is more aggressive Project
dissolution, as described in the OpenJDK Bylaws:
"A Project’s Committers may decide, by Lazy Consensus,
to request explicitly that the Project be dissolved.
... When a Project is dissolved its materials are archived."
I read this as "ONLY when a Project is dissolved, are its materials
archived." People would be confused if a Project's list was archived on
the mailing list server, but the Project's page on
http://openjdk.java.net/ and its repos at http://hg.openjdk.java.net/
are silent about status.
I guess it's possible for a Project to follow the lead of Project Lambda
(http://openjdk.java.net/projects/lambda/) by declaring on its page that
the Project is "complete" (but not dissolved) and that further
communication should use so-and-so channels. But that is work for a
Project Lead beyond merely agreeing that their lists can be archived.
On 3/13/2019 6:53 AM, Adam Farley8 wrote:
> I agree with all of the points in Brian's email.
> This initial email chain is to show the problem, and to gather popular
> support for a large-scale cleanup, prior to approaching the list owners.
> Plus, this gives people a chance to add/remove lists like Brian has done,
> and also to identify any "overall list management" group who should be
> consulted before pursuing this task.
> Best Regards
> Adam Farley
> IBM Runtimes
> Brian Goetz <brian.goetz at oracle.com> wrote on 13/03/2019 13:18:16:
>> From: Brian Goetz <brian.goetz at oracle.com>
>> To: Adam Farley8 <adam.farley at uk.ibm.com>
>> Cc: discuss at openjdk.java.net
>> Date: 13/03/2019 13:23
>> Subject: Re: Proposal: Mailing List Cull
>> Without commenting on the specific proposal, I agree that having a
>> lot of “dead” mailing lists both (a) could give off the appearance
>> of being a ghost town and (b) makes it harder to find where the
>> active discussion is. Given that many lists are for projects that
>> are no longer active (some just ran off the road, others completed
>> their mission and should be wound down), some move to guide users to
>> the active lists while preserving the history of the inactive lists
>> would be good.
>> Note that Proposal 3 is really a separate question from the “how do
>> we display mailing lists” question; it is really about creating a
>> “start here” page, which is orthogonal to how the mailing lists are
>> organized and displayed.
>> The next steps can be taken in parallel:
>> - Determine a course of action for dealing with dead / dormant lists
>> (this is mostly a discussion task);
>> - Determine the actual deadness / dormancy status of the lists that
>> you identified. This is a research task. The place to start here
>> is to go to the project leads for the owning projects or the group
>> leads for the owning groups, and ask them if there is some reason
>> they are more active than they appear.
>>> On Mar 13, 2019, at 8:27 AM, Adam Farley8 <adam.farley at uk.ibm.com>
>>> (Preface: I may be sending this to the wrong list, so advice on the
>>> correct list would be appreciated.)
>>> Hey All,
>>> There's a lot of mailing lists here, including a few that've been dead
>>> 5 years, and I think it's making it hard for contributors to find the
>>> right list.
>>> Here's a list of mailing lists seeing no/minimal use, and a set of
>>> proposals to go with them.
>>> Proposal 1: Cull (archive) one or more of these mailing list groups,
>>> exceptions made for lists anyone still wants, or actively monitors.
>>> Why? Because having 151 non-archived mailing lists makes it harder for
>>> people to find the right one. Also makes it easier to find black holes
>>> (non-monitored lists) to drop valid bugs into.
>>> Proposal 2: Hide the archived mailing lists on the primary "mailing
>>> Why? Because it dilutes the list of active lists and makes finding the
>>> right one harder.
>>> Proposal 3: Create a short list of the most useful channels to the
>>> contributor, making it easier to find the primary hotspot, JCL, docs
>>> lists, etc.
>>> Why? Ease of use. Ability to contribute should be based on knowledge
>>> the code base, not knowledge of the mailing lists,
>>> Proposal 4: Hide the mailing lists whose sole purpose is to display
>>> automated messages when a project has been committed to.
>>> Proposal 4: Make Proposals 2, 3, and 4 the default view when you click
>>> "Mailing lists" from the main page.
>>> Why? Ease of use again. One form this could take is: the user clicks
>>> "mailing lists" on the primary openjdk page, and sees a minimal list
>>> mailing lists, with toggles to show the lists hidden by 2, 3, and 4.
>>> Constructive opinions welcome. :)
>>> Best Regards
>>> Adam Farley
>>> IBM Runtimes
>>> P.S. Spam and "hep please" don't count as emails.
>>> -- Appendix list:
>>> 1: Lists with no emails in 2 years or more. (Dead)
>>> 2: Lists with no emails inside the last 6 months. (Presumed Dead)
>>> 3: Lists with less than 2 emails (average) per month for the past year
>>> -- Appendix 1: (Dead)
>>> -- Appendix 2: (Presumed Dead)
>>> -- Appendix 3: (Rosebud)
>>> Unless stated otherwise above:
>>> IBM United Kingdom Limited - Registered in England and Wales with
>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
More information about the discuss