I'm sorry to be so late on this... I am going to write here for visibility, and I'll also add or see to add it correctly the sheet initiated by Oleg.
1. I would like to help facilitate a conversation on Guava upgrade in Jenkins Core.
As you know, this work is already somehow started. I'd like us to take the summit opportunity to decide on next steps, approaches.
Our team at CloudBees is committed to help on this subject.
2. Plugin EOL policy // plugin maintenance status
I think these two subjects would serve us as a community to keep moving Jenkins forward.
For the commons-digester:2.1 recent removal for instance, I think we spent a subtantial amount of effort on plugins nobody should use anymore since a long time.
If we had had such a policy, we could have saved a lot of energy together.
3. Company/team ownership for plugins
As an ex-HOSTING team member and a contributor since a few years, I think we need to have a clearer stance for companies to implement a Jenkins plugin for their software.
It happens regularly than a company, not intimate with the Jenkins Project's governance, will request commit access to a plugin they think they own somehow. (e.g. HOSTING-901, HOSTING-346, HOSTING-288, HOSTING-134, and we could go on)
Only then they discover that from the Jenkins Project's standpoint, they do not exist. An ex-employee that may have even left a given company could disagree to let commit rights go and they would be entitled to this (fortunately didn't happen yet, to my knowledge).
The other case I've got in mind is the "team" concept. That's the one I'm most interested in personally. For example, when people move between teams in our company etc., we usually need to update many files in RPU and request commit access in various repositories.
If we could have an official concept for teams within the Jenkins Project, I think we could set up special GH teams (for example one for ours at CloudBees) + create possibly such a concept for it inside RPU to define this only once.
I think this is already doable (we already have the core team within GH e.g.), and we could request an ad-hoc implementation and move on. But I think there's merit in defining something generalized for the Jenkins Project's governance.
Thanks for reading :). I definitely didn't plan to send such a long email.
Have a great weeked everyone.