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


AreaSuggested bycurrent statesuggestionreasoning in favor ofReasoning against
structureKeong Limeither 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.

structureAlexis de Talhouëteither 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.



























  • No labels