Hi,
That's IMO a good discussion and a good goal.
Let's add some constraints to make it manageable for the project and still be acceptable for Eclipse governance POV:
* The Eclipse Development Process
https://www.eclipse.org/projects/dev_process/ mandates that at least 1 mailing-lists is used by the project, the "Developer mailing-lists" which is to be used for organisational project management (eg committer election or other forms of decision based on votes of committers). While there are ongoing discussion in the Architecture Council to allow to move this to other media (eg GitHub discussion), we shouldn't expect this to change anytime soon. So *keeping the tycho-dev mailing list and committers monitoring it is a hard requirement*.
* We shouldn't add 1 new channel without removing another; otherwise we just scatter data, community, knowledge, workflows... So let's make a hard requirement that we can add GitHub discussions only if we get rid of 1 mailing-lists. With the previous constraint that makes tycho-dev has to remain, the requirement becomes *if we enable GitHub discussions, then tycho-user mailing-list has to be deactivated*.
* The tycho-user mailing-list is a very big knowledge base, many usual issues have solutions that are only available on this mailing-list; many discussions on several medias do link to the tycho-user archive. So *we shouldn't deactivate tycho-user mailing-list if there is a risk of data/link loss*
* Eclipse mailing-lists has some SLA (provided by EMO) about data backup and persistence which kind of guarantees that they should never be lost. What is the SLA for GitHub discussions
Summary of constraints:
1. keeping the tycho-dev mailing list and committers monitoring it is a hard requirement
2. if we enable GitHub discussions, then tycho-user mailing-list has to be deactivated
3. we shouldn't deactivate tycho-user mailing-list if there is a risk of data/link loss
4. a- we should ensure GitHub discussions have some guarantees about data being backed-up and openly accessible for the whole lifetime of the project; or b- EMO has backup strategies for GitHub discussions (similarly to what they have for the code and issues IIRC)
I'll get in touch with the EMO Infra team about items 3 a 4.b. If this is possible, then I think we can proceed to replacement of tycho-user by GitHub discussions.
Please someone investigate item 4.a.
