Proposal: Mailing List Cull

[Adam Farley8]

Hi Alex, Jeff,

Jeff: Thanks for responding there. Your list has been removed from the 
appendices, as it's still wanted.

Alex: What I'm imagining is a smaller number of active lists.

You're right to assert that active projects should have a mailing list, 
and it is not my intention to imply otherwise.

Perhaps less active (read: near-silent), or completed, projects could 
share a common list, or use one of the more active lists?

This would need to be mentioned on the project page, yes.

And speaking of common lists, I keep having to copy the Appendices between 
my emails to ensure changes aren't lost.

This invites errors, so here's a JBS Task to store the shared list where 
everyone can tweak it:

https://bugs.openjdk.java.net/browse/JDK-8220662

Unsure if this is a misuse of the bug system. I expect someone will 
complain if it is. :)

Best Regards

Adam Farley 
IBM Runtimes


"discuss" <discuss-bounces at openjdk.java.net> wrote on 13/03/2019 19:28:26:

> From: Alex Buckley <alex.buckley at oracle.com>
> To: discuss at openjdk.java.net
> Date: 13/03/2019 19:50
> Subject: Re: Proposal: Mailing List Cull
> Sent by: "discuss" <discuss-bounces at openjdk.java.net>
> 
> 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:
> 
>    https://urldefense.proofpoint.com/v2/url?
> u=http-3A__openjdk.java.net_bylaws-23-5F6&d=DwIFaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=P5m8KWUXJf-
> 
CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=xHgfLFByqwNSfZ49CIKNKMW0JGEFUA8ZB1N3rw_4G_0&s=ptkTcpz7zHeI-
> xE-2gCB-Uned4rtbaMoBaJ4vN9iaMU&e=
> 
>    "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 
> https://urldefense.proofpoint.com/v2/url?
> u=http-3A__openjdk.java.net_&d=DwIFaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=P5m8KWUXJf-
> 
CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=xHgfLFByqwNSfZ49CIKNKMW0JGEFUA8ZB1N3rw_4G_0&s=hjSGZG1CMxTw3UAURV9vx8kgTSvLoaJ8zlwVyRVUE0Y&e=
> and its repos at https://urldefense.proofpoint.com/v2/url?
> u=http-3A__hg.openjdk.java.net_&d=DwIFaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=P5m8KWUXJf-
> 
CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=xHgfLFByqwNSfZ49CIKNKMW0JGEFUA8ZB1N3rw_4G_0&s=F6mPKb6KGHcmKiegV8UTCL_7oIegTWxkyTJ0TM8dxe8&e=
> are silent about status.
> 
> I guess it's possible for a Project to follow the lead of Project Lambda 

> (https://urldefense.proofpoint.com/v2/url?
> u=http-3A__openjdk.java.net_projects_lambda_&d=DwIFaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=P5m8KWUXJf-
> 
CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=xHgfLFByqwNSfZ49CIKNKMW0JGEFUA8ZB1N3rw_4G_0&s=qaUJuq9tbh_pTfNNbMsRd7I29IuWjGF9TB0SFC0bDxo&e=
> ) 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
> >
> 

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