Proposal: Mailing list retirement plan #452

New issue

Open

opened 2023-05-02 17:23:33 +00:00 by sgallagh · 16 comments

sgallagh commented 2023-05-02 17:23:33 +00:00

Copy link

A proposal was brought to FESCo to decide on whether there should be an inactive list policy for Fedora. FESCo collectively agreed that such a policy should rightfully be decided upon at the Council level.

With that in mind, I have the following specific proposal to offer for the purposes of starting the discussion:

Any list that hasn't seen a message for the last four Fedora release cycles will be archived.

A proposal was brought to FESCo to decide on whether there should be an inactive list policy for Fedora. FESCo collectively agreed that such a policy should rightfully be decided upon at the Council level. With that in mind, I have the following specific proposal to offer for the purposes of starting the discussion: _Any list that hasn't seen a message for the last four Fedora release cycles will be archived._

jflory7 commented 2023-05-03 02:24:06 +00:00

Contributor

Copy link

Metadata Update from @jflory7:

• Issue tagged with: policies

**Metadata Update from @jflory7**: - Issue tagged with: policies

jflory7 commented 2023-05-03 02:26:51 +00:00

Contributor

Copy link

For some reason, the Discourse bot did not repeat this Pagure issue to GitLab. I suspect we will want that relay because I don't think this is a ticket that will be resolved quickly.

Is there a link to the discussion that kicked this topic off in FESCo? I am curious of the context behind this ask.

Generally, inactivity for four release cycles seems fair. That is two years. I'm not sure whether this should be applied universally or if we should start with something else, i.e. no new mailing lists without getting an exception approved?

For some reason, the Discourse bot did not repeat this Pagure issue to GitLab. I suspect we will want that relay because I don't think this is a ticket that will be resolved quickly. Is there a link to the discussion that kicked this topic off in FESCo? I am curious of the context behind this ask. Generally, inactivity for four release cycles seems fair. That is two years. I'm not sure whether this should be applied universally or if we should start with something else, i.e. no new mailing lists without getting an exception approved?

fed500 commented 2023-05-04 13:23:00 +00:00

Copy link

See https://meetbot.fedoraproject.org/fedora-meeting/2023-05-02/fesco.2023-05-02-17.00.log.html and https://pagure.io/fesco/issue/2982

See https://meetbot.fedoraproject.org/fedora-meeting/2023-05-02/fesco.2023-05-02-17.00.log.html and https://pagure.io/fesco/issue/2982

mattdm commented 2023-05-04 16:07:00 +00:00

Copy link

t2dbot got disconnected from the message bus and my error-handling code is not very robust. :)

Discussion here: https://discussion.fedoraproject.org/t/fedora-council-tickets-ticket-452-proposal-mailing-list-retirement-plan/82079

t2dbot got disconnected from the message bus and my error-handling code is not very robust. :) Discussion here: https://discussion.fedoraproject.org/t/fedora-council-tickets-ticket-452-proposal-mailing-list-retirement-plan/82079

amoloney commented 2024-07-16 17:07:32 +00:00

Copy link

@sgallagh Is this still needed? I think the proposal is solid and would like to work on it with other council members to formalise a policy. The points raised in the discussion thread about retention for historical purposes is valid, so I would like to pursue a policy that incorporates a 'de-activation' based on activity as you suggested.

It may be a good first step towards overall retirement of our mailing lists, save for devel-announce and maybe one or two others.

@sgallagh Is this still needed? I think the proposal is solid and would like to work on it with other council members to formalise a policy. The points raised in the discussion thread about retention for historical purposes is valid, so I would like to pursue a policy that incorporates a 'de-activation' based on activity as you suggested. It may be a good first step towards overall retirement of our mailing lists, save for devel-announce and maybe one or two others.

amoloney commented 2024-07-16 17:07:32 +00:00

Copy link

Metadata Update from @amoloney:

• Issue priority set to: None (was: 1)

**Metadata Update from @amoloney**: - Issue priority set to: None (was: 1)

sgallagh commented 2024-07-18 15:32:28 +00:00

Author

Copy link

@sgallagh Is this still needed? I think the proposal is solid and would like to work on it with other council members to formalise a policy. The points raised in the discussion thread about retention for historical purposes is valid, so I would like to pursue a policy that incorporates a 'de-activation' based on activity as you suggested.

It may be a good first step towards overall retirement of our mailing lists, save for devel-announce and maybe one or two others.

That sounds fine to me.

> @sgallagh Is this still needed? I think the proposal is solid and would like to work on it with other council members to formalise a policy. The points raised in the discussion thread about retention for historical purposes is valid, so I would like to pursue a policy that incorporates a 'de-activation' based on activity as you suggested. > > It may be a good first step towards overall retirement of our mailing lists, save for devel-announce and maybe one or two others. That sounds fine to me.

amoloney commented 2025-02-07 09:22:45 +00:00

Copy link

@mattdm will work on this ticket

@mattdm will work on this ticket

amoloney commented 2025-02-07 09:22:45 +00:00

Copy link

Metadata Update from @amoloney:

• Issue assigned to mattdm

**Metadata Update from @amoloney**: - Issue assigned to mattdm

jflory7 commented 2025-05-23 20:24:51 +00:00

Contributor

Copy link

Hey y'all, I am proposing an initial draft for a policy regarding the archival of inactive Fedora Project mailing lists. The primary goals are to help focus our community communication channels, reduce the maintenance burden of unused lists, and gently encourage the use of more centralized platforms like Fedora Discussion, all while ensuring the preservation of the valuable historical record contained in our mailing lists.

Over the past several years, the way our community communicates has evolved, and it's important that our infrastructure and policies adapt to best support our contributors and users.

Below is a very early first draft of a "Fedora Project Mailing List Archival Policy." This proposal is based on the initial idea by @sgallagh and aims to incorporate considerations for historical preservation, clear definitions of inactivity, and a process for managing these lists.

We are currently in an initial feedback gathering phase for this draft. The intention is to discuss and refine this proposal, particularly with input from the Council and other interested community members, to develop a version we are confident in.

Once a more finalized draft is prepared, the Fedora Council will then initiate the formal Fedora Council's Policy Change Policy. That process includes public announcements on the #council tag on Fedora Discussion and in a Fedora Community Blog post, followed by a minimum two-calendar-week community feedback period before any Council vote.

For now, we encourage you to review this preliminary draft and provide constructive feedback to help us shape it. Your early input is valuable as we work towards a formal proposal.

Draft: Fedora Project Mailing List Archival Policy

1. Purpose

This policy outlines the process for archiving inactive Fedora Project mailing lists. The objectives are:

• To streamline community communication channels and reduce fragmentation.
• To lessen the administrative overhead associated with maintaining a large number of inactive mailing lists.
• To encourage the use of currently preferred communication platforms within the Fedora Project.
• To ensure a best-effort preservation of the historical content of Fedora Project mailing lists for their reference value.

2. Scope

This policy applies to all mailing lists hosted on Fedora Project infrastructure servers, including those under domains such as *.fedoraproject.org, *.fedorahosted.org, or other domains utilizing Fedora Project's shared mailing list infrastructure, with the explicit exception of the following critical lists:

• devel@lists.fedoraproject.org
• devel-announce@lists.fedoraproject.org
• announce@lists.fedoraproject.org
• test-announce@lists.fedoraproject.org

These exempted lists are considered vital for project-wide communication and development coordination and are not subject to archival under this inactivity policy. All other mailing lists are within the scope of this policy.

3. Definition of Inactivity

A mailing list within the scope of this policy will be considered "inactive" if it has had no legitimate, human-generated, on-topic discussion messages posted by a Fedora community member for a period of three (3) consecutive Fedora Linux release cycles (approximately 1.5 years).

• Automated messages (e.g., build system notifications, cron job outputs unless directly fostering discussion), spam, or messages not relevant to the list's stated purpose do not constitute activity for the purposes of this policy.
• A single legitimate, human-generated, on-topic message resets the inactivity period for that list.

4. Archival Process

4.1. Identification of Inactive Lists:

• Initially, inactive lists may be identified for archival through periodic manual review by the Fedora Infrastructure team or upon request from a list owner, a Fedora leadership body (e.g., Fedora Council, FESCo, Mindshare Committee), or any Fedora community member.
• Requests for archival should be directed to the Fedora Infrastructure team.

4.2. Notification of Pending Archival:

• Upon identification of a list as inactive and eligible for archival, the Fedora Infrastructure team (or a delegate) will notify the registered list owner(s).
• The notification will:
  • State that the list has been identified for archival due to inactivity, referencing this policy.
  • Specify the date of the last known legitimate activity.
  • Inform the owner(s) of a 30-calendar-day window to object to the archival.
  • Clarify that if the list is archived, reactivation requires an appeal to the Fedora Council.
  • May gently suggest alternative platforms like Fedora Discussion for continued community interaction.
  • Include a link to this "Fedora Project Mailing List Archival Policy" document.

4.3. List Owner Response and Opt-Out:

• The list owner(s) have 30 calendar days from the date of notification to respond.
• A simple statement from a registered list owner expressing a desire to keep the list active is sufficient to halt the current archival process for that list. The list will then be considered active, and the inactivity clock will reset.
• If no objection is received from a registered list owner within the 30-day window, or if the list owner(s) explicitly consent to the archival, the list will proceed to be archived.

4.4. Archival Action:

• The Fedora Infrastructure team will configure the mailing list to be read-only. No new messages will be accepted for posting.
• Attempts to send messages to the archived list address will result in a bounce notification.
• The existing archives of the list will remain publicly accessible via their original URLs on lists.fedoraproject.org (or its successor archive system) on a best-effort basis.

5. Reactivation of Archived Lists

• Requests to reactivate a previously archived mailing list must be submitted to the Fedora Council.
• The Fedora Council will review such requests and may approve reactivation under exceptional circumstances, considering the justification provided and the current needs of the project.
• If approved, the Fedora Infrastructure team will facilitate the reactivation.

6. Historical Data Preservation

The Fedora Project is committed to a best-effort attempt to preserve the read-only archives of all mailing lists (including those archived under this policy) due to their significant historical value to the project and the broader open source community. While the specific technical methods of archival and presentation may evolve, the intent is to maintain long-term public access to this historical data. This policy does not guarantee the permanency of specific URLs or archival formats indefinitely, as technology and infrastructure will change over time.

7. Policy Review

This policy will be reviewed periodically by the Fedora Council and may be updated as needed to reflect the evolving communication needs and infrastructure of the Fedora Project.

Please share your thoughts and feedback on this proposal.

Hey y'all, I am proposing an initial draft for a policy regarding the archival of inactive Fedora Project mailing lists. The primary goals are to help focus our community communication channels, reduce the maintenance burden of unused lists, and gently encourage the use of more centralized platforms like Fedora Discussion, all while ensuring the preservation of the valuable historical record contained in our mailing lists. Over the past several years, the way our community communicates has evolved, and it's important that our infrastructure and policies adapt to best support our contributors and users. Below is a **very early first draft** of a "Fedora Project Mailing List Archival Policy." This proposal is based on the initial idea by @sgallagh and aims to incorporate considerations for historical preservation, clear definitions of inactivity, and a process for managing these lists. **We are currently in an initial feedback gathering phase for this draft**. The intention is to discuss and refine this proposal, particularly with input from the Council and other interested community members, to develop a version we are confident in. **Once a more finalized draft is prepared, the Fedora Council will then initiate the formal Fedora Council's [Policy Change Policy](https://docs.fedoraproject.org/en-US/council/policies/policy-change-policy/)**. That process includes public announcements on the `#council` tag on Fedora Discussion and in a Fedora Community Blog post, followed by a minimum two-calendar-week community feedback period before any Council vote. For now, we encourage you to review this preliminary draft and provide constructive feedback to help us shape it. Your early input is valuable as we work towards a formal proposal. # Draft: Fedora Project Mailing List Archival Policy > ## 1. Purpose > > This policy outlines the process for archiving inactive Fedora Project mailing lists. The objectives are: > > * To streamline community communication channels and reduce fragmentation. > * To lessen the administrative overhead associated with maintaining a large number of inactive mailing lists. > * To encourage the use of currently preferred communication platforms within the Fedora Project. > * To ensure a best-effort preservation of the historical content of Fedora Project mailing lists for their reference value. > > ## 2. Scope > > This policy applies to all mailing lists hosted on Fedora Project infrastructure servers, including those under domains such as `*.fedoraproject.org`, `*.fedorahosted.org`, or other domains utilizing Fedora Project's shared mailing list infrastructure, with the explicit exception of the following critical lists: > > * `devel@lists.fedoraproject.org` > * `devel-announce@lists.fedoraproject.org` > * `announce@lists.fedoraproject.org` > * `test-announce@lists.fedoraproject.org` > > These exempted lists are considered vital for project-wide communication and development coordination and are not subject to archival under this inactivity policy. All other mailing lists are within the scope of this policy. > > ## 3. Definition of Inactivity > > A mailing list within the scope of this policy will be considered "inactive" if it has had no legitimate, human-generated, on-topic discussion messages posted by a Fedora community member for a period of three (3) consecutive Fedora Linux release cycles (approximately 1.5 years). > > * Automated messages (e.g., build system notifications, cron job outputs unless directly fostering discussion), spam, or messages not relevant to the list's stated purpose do not constitute activity for the purposes of this policy. > * A single legitimate, human-generated, on-topic message resets the inactivity period for that list. > > ## 4. Archival Process > > ### 4.1. Identification of Inactive Lists: > > * Initially, inactive lists may be identified for archival through periodic manual review by the Fedora Infrastructure team or upon request from a list owner, a Fedora leadership body (e.g., Fedora Council, FESCo, Mindshare Committee), or any Fedora community member. > * Requests for archival should be directed to the Fedora Infrastructure team. > > ### 4.2. Notification of Pending Archival: > > * Upon identification of a list as inactive and eligible for archival, the Fedora Infrastructure team (or a delegate) will notify the registered list owner(s). > * The notification will: > * State that the list has been identified for archival due to inactivity, referencing this policy. > * Specify the date of the last known legitimate activity. > * Inform the owner(s) of a 30-calendar-day window to object to the archival. > * Clarify that if the list is archived, reactivation requires an appeal to the Fedora Council. > * May gently suggest alternative platforms like Fedora Discussion for continued community interaction. > * Include a link to this "Fedora Project Mailing List Archival Policy" document. > > ### 4.3. List Owner Response and Opt-Out: > > * The list owner(s) have 30 calendar days from the date of notification to respond. > * A simple statement from a registered list owner expressing a desire to keep the list active is sufficient to halt the current archival process for that list. The list will then be considered active, and the inactivity clock will reset. > * If no objection is received from a registered list owner within the 30-day window, or if the list owner(s) explicitly consent to the archival, the list will proceed to be archived. > > ### 4.4. Archival Action: > > * The Fedora Infrastructure team will configure the mailing list to be read-only. No new messages will be accepted for posting. > * Attempts to send messages to the archived list address will result in a bounce notification. > * The existing archives of the list will remain publicly accessible via their original URLs on `lists.fedoraproject.org` (or its successor archive system) on a best-effort basis. > > ## 5. Reactivation of Archived Lists > > * Requests to reactivate a previously archived mailing list must be submitted to the Fedora Council. > * The Fedora Council will review such requests and may approve reactivation under exceptional circumstances, considering the justification provided and the current needs of the project. > * If approved, the Fedora Infrastructure team will facilitate the reactivation. > > ## 6. Historical Data Preservation > > The Fedora Project is committed to a best-effort attempt to preserve the read-only archives of all mailing lists (including those archived under this policy) due to their significant historical value to the project and the broader open source community. While the specific technical methods of archival and presentation may evolve, the intent is to maintain long-term public access to this historical data. This policy does not guarantee the permanency of specific URLs or archival formats indefinitely, as technology and infrastructure will change over time. > > ## 7. Policy Review > > This policy will be reviewed periodically by the Fedora Council and may be updated as needed to reflect the evolving communication needs and infrastructure of the Fedora Project. Please share your thoughts and feedback on this proposal.

jflory7 commented 2025-05-23 20:25:55 +00:00

Contributor

Copy link

Metadata Update from @jflory7:

• Issue assigned to jflory7 (was: mattdm)

**Metadata Update from @jflory7**: - Issue assigned to jflory7 (was: mattdm)

ngompa commented 2025-05-23 21:12:20 +00:00

Copy link

How would this policy work if we wanted this for Discourse? How would we wind down unused sections, tags, etc. there? Because if you're making such a policy for mailing lists, you need an equivalent for all communication mechanisms.

How would this policy work if we wanted this for Discourse? How would we wind down unused sections, tags, etc. there? Because if you're making such a policy for mailing lists, you need an equivalent for _all_ communication mechanisms.

jflory7 commented 2025-05-26 21:26:46 +00:00

Contributor

Copy link

Hi @ngompa, you've raised an excellent point about the need for similar guidance there, which is certainly something for future consideration. This current proposal, however, is intentionally focused solely on mailing lists as part of our specific effort to wind down that older platform. Mailing lists have different archival ramifications and stakeholder groups (primarily Infrastructure and list owners) compared to Fedora Discussion (which involves its moderators, Ask Fedora, and contributor teams). Addressing both now would expand the scope of this ticket too much, but I agree that a dedicated discussion for Fedora Discussion policy will be valuable down the line, likely led by those closer to its day-to-day management.

Hi @ngompa, you've raised an excellent point about the need for similar guidance there, which is certainly something for future consideration. This current proposal, however, is intentionally focused _solely_ on mailing lists as part of our specific effort to wind down that older platform. Mailing lists have different archival ramifications and stakeholder groups (primarily Infrastructure and list owners) compared to Fedora Discussion (which involves its moderators, Ask Fedora, and contributor teams). Addressing both now would expand the scope of this ticket too much, but I agree that a dedicated discussion for Fedora Discussion policy will be valuable down the line, likely led by those closer to its day-to-day management.

ngompa commented 2025-05-26 21:42:40 +00:00

Copy link

our specific effort to wind down that older platform

Who specifically said we wanted this as a community? Because that's news to me.

> our specific effort to wind down that older platform Who specifically said we wanted this as a community? Because that's news to me.

jflory7 commented 2025-05-26 22:11:57 +00:00

Contributor

Copy link

@ngompa That's a fair point to raise regarding the broader community discussion on the future of our communication platforms. There have indeed been ongoing conversations about evolving our strategy here, since this ticket is already over two years old. It is also true that a long-term vision articulated by Matthew involves greater consolidation towards platforms like Fedora Discussion.

This specific proposal for archiving inactive mailing lists focuses on the stated goals within this ticket: to streamline our channels, reduce the maintenance burden of unused lists, and gently encourage use of more modern platforms.

For a more in-depth discussion on the overall strategic direction and to pose questions like these to the Council directly, the upcoming Fedora Council AMA at Flock is an excellent venue.

@ngompa That's a fair point to raise regarding the broader community discussion on the future of our communication platforms. There have indeed been ongoing conversations about evolving our strategy here, since this ticket is already over two years old. It is also true that a long-term vision articulated by Matthew involves greater consolidation towards platforms like Fedora Discussion. This specific proposal for archiving inactive mailing lists focuses on the stated goals within this ticket: to streamline our channels, reduce the maintenance burden of unused lists, and gently encourage use of more modern platforms. For a more in-depth discussion on the overall strategic direction and to pose questions like these to the Council directly, the upcoming [Fedora Council AMA at Flock](https://discussion.fedoraproject.org/t/questions-for-the-fedora-council-ama-session-at-flock/154437) is an excellent venue.

kevin commented 2025-05-27 16:39:25 +00:00

Copy link

One slight technical issue: The way we set lists 'read-only' is just to set message acceptance to reject/bounce, etc.
However, those settings are something the lists owners can change, so a list owner would be able to 'un read only' a list.
I suspect the chances are low of that, but thought I would mention it.

There's a number of other active lists for various other purposes, but since they are active, they wouldn't be affected here...

Otherwise seems fine to me.

One slight technical issue: The way we set lists 'read-only' is just to set message acceptance to reject/bounce, etc. However, those settings are something the lists owners can change, so a list owner would be able to 'un read only' a list. I suspect the chances are low of that, but thought I would mention it. There's a number of other active lists for various other purposes, but since they are active, they wouldn't be affected here... Otherwise seems fine to me.

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

No results found.

Labels

Clear labels   

budget

  

Closed As

approved

Closed with the reason of approved

  

Closed As

declined

Closed with the reason of declined

  

Closed As

deferred

Closed with the reason of deferred

  

Closed As

duplicate

Closed with the reason of duplicate

  

Closed As

no action needed

Closed with the reason of no action needed

  

Closed As

resolved

Closed with the reason of resolved

  

code-of-conduct

  

documentation

  

elections

  

events

  

hackfests

  

initiatives

  

In Progress

Topics that are being actively discussed orworked on

  

mindshare

  

Needs Review

  

Next Meeting

For tickets that need to be discussed at the next council meeting

  

policies

  

spending-request

"Budget" is for big-picture things. This is for as-we-go allocations.

  

ticket-vote

Hey, council members: Let's vote on this in this ticket, right now!

  

trademarks

  

urgent

No labels

budget

Closed As

approved

Closed As

declined

Closed As

deferred

Closed As

duplicate

Closed As

no action needed

Closed As

resolved

code-of-conduct

documentation

elections

events

hackfests

initiatives

In Progress

mindshare

Needs Review

Next Meeting

policies

spending-request

ticket-vote

trademarks

urgent

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

7 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Council/tickets#452

No description provided.