Proposal: Mailing List Cull

[Alex Buckley]

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:

   http://openjdk.java.net/bylaws#_6

   "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.

Alex

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>
> wrote:
>>>
>>> (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
> for
>>> 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,
> with
>>> 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
> lists"
>>> view.
>>> 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
> casual
>>> 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
> of
>>> 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
> on
>>> "Mailing lists" from the main page.
>>> Why? Ease of use again. One form this could take is: the user clicks
> on
>>> "mailing lists" on the primary openjdk page, and sees a minimal list
> of
>>> 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
>
>>> (Rosebud)
>>>
>>> -- Appendix 1: (Dead)
>>> anno-pipeline-dev
>>> btrace-dev
>>> compiler-grammar-dev
>>> cvmi-dev
>>> friday-stats-dev
>>> graphics-rasterizer-dev
>>> guide-discuss
>>> icedtea-changes
>>> java-se-8-spec-comments
>>> java-se-8-spec-experts
>>> java-se-8-spec-observers
>>> java-se-9-spec-comments
>>> java-se-9-spec-experts
>>> java-se-mr-spec-comments
>>> javadoc-next-dev
>>> jep-changes
>>> kona-dev
>>> lambda-libs-spec-comments
>>> lambda-libs-spec-experts
>>> lambda-libs-spec-observers
>>> penrose-dev
>>> penrose-discuss
>>> tiered-attrib-dev
>>> type-annotations-dev
>>> type-annotations-spec-comments
>>> type-annotations-spec-experts
>>> type-annotations-spec-observers
>>> xrender-dev
>>>
>>> -- Appendix 2: (Presumed Dead)
>>> detroit-dev
>>> dio-dev
>>> duke-dev
>>> graal-changes
>>> haiku-port-dev
>>> harfbuzz-dev
>>> icedtea-test
>>> java-se-9-spec-observers
>>> java-se-spec-comments
>>> jdk-hs-changes
>>> jmm-dev
>>> nb-projects-dev
>>> nio-discuss
>>> panama-spec-experts
>>> sandbox-changes
>>> sctp-dev
>>> sumatra-dev
>>> valhalla-spec-comments
>>>
>>> -- Appendix 3: (Rosebud)
>>> asmtools-dev
>>> caciocavallo-dev
>>> conformance-discuss
>>> doccheck-dev
>>> jmx-dev
>>> jol-dev
>>> lambda-spec-comments
>>> lambda-spec-experts
>>> lambda-spec-observers
>>> macosx-port-dev
>>> metropolis-dev
>>> mips-port
>>> platform-jep-discuss
>>>
>>>
>>>
>>> Unless stated otherwise above:
>>> IBM United Kingdom Limited - Registered in England and Wales with
> number
>>> 741598.
>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
>>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>