Mailing Lists 2.0

Owned by Kenny Paul
Jan 25, 2019
1 min read

A page to collect ideas on an updated approach to ONAP mailing list management.



Area

Suggested by

current state

suggestion

reasoning in favor of

Reasoning against

Area

Suggested by

current state

suggestion

reasoning in favor of

Reasoning against

structure

@Keong Lim

either one big list with tags and a few project specific lists

thresholds defined for combining/splitting mailing lists based on the amount of traffic they receive, e.g.

  • if the total message traffic on all lists is less than X msg/day, then everyone should use onap-discuss list

  • if the message traffic on onap-discuss list goes over Y msg/day, then split it into another sub-group

  • if the message traffic on a sub-group goes under Z msg/day, then re-combine it back with onap-discuss list

The community can vote on setting the thresholds for X, Y and Z as appropriate to balance the concerns, i.e.

  • receiving too many messages

  • annoying too many people with messages

  • finding relevant topics amongst the messages

  • administering multiple sub-groups and lists

  • the amount of cross-posting to many sub-groups

@Alexis de Talhouët

I’m not sure we should look at traffic within the mailing list to define whether it’s valuable or not. As time will evolve, projects within a certain domain will mature, hence mail traffic will reduce.

Also, it is easier to know where to look for mail information for a given domain.

structure

@Alexis de Talhouët

either one big list with tags and a few project specific lists

mailing list per domain, e.g. controller, orchestration, analytics, inventory, message-bus, etc… rather than having a mailing-list per project. 

Given the number of project, this would be hard

to navigate and look for information.