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 |
---|---|---|---|---|---|
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.
| The community can vote on setting the thresholds for X, Y and Z as appropriate to balance the concerns, i.e.
| 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. | |