On Thu, Dec 13, 2018 at 01:47:30PM -0500, Josh Boyer wrote: > I cannot tell from the writeup below if it is documenting existing > practice, describing an ideal end state to be worked towards, or > somewhere in between. I read this less as a guiding policy and more > as an idea. I realize these topics are very difficult to draft > properly, particularly in a consumable format without the context of a > 3 day meeting behind them. This is an ideal we'd like the project to work towards, but it's also a path that we're already on. There's some more context in a meeting report we're getting ready to post; hopefully some of that will help. > Can we approach the topic a different way? Perhaps by saying what you > believe needs to materially *change* to make this a reality? 1. We want "Fedora" to be the Project. For things Fedora makes, describe them as "Fedora Thingname", like "Fedora IoT" or "the Fedora RPM Package Collection". I've been saying this for a while, but I want to make it official. (Just as "Red Hat" isn't RHEL.) 2. We're going to set up a (hosted) Taiga instance. Anyone in Fedora will be able to create a project there, and *every team in Fedora should*. This will create a directory listing which will supplant https://fedoraproject.org/wiki/Subprojects and have three significant advantages: 1. Available all in one place 2. Searchable in a reasonable, non-wiki way 3. Not a wiki: inherently self-updating and sortable by activity This is the minimum required to be a Fedora Team. A Team with no formal membership process other than signing up and no formal structure is a SIG. Other Teams may have more formalized membership, a charter with rules for voting, regular meetings, regular reports to FESCo or Mindshare, etc. (We decided against formalizing rules for words like "Working Group" or "Subproject" and instead agreed that any Team more formal than a SIG can use those labels if they like.) More on Taiga and this directory-service idea to come soon. 3. Teams providing services should formalize a menu of offerings. They should describe the criteria by which those offerings are... offered. I think the Council should provide some standard ideas for reasonable criteria. These could include team structure and activity level, user base, a link to current Fedora Objective, etc. 4. We need a way for Teams to release artifacts in a self-service way. The Astronomy spin (to pick a random example) should not need to wait for release engineering to make a release. In fact, they might choose to make new releases around the cadence of their most important included software. At the same time, since the Team can do it themselves, Release Engineering might also not be on the hook for building artifacts for spins with a niche audience or that don't meet some other criteria. 5. We need to allow for non-RPM building blocks somehow. I mean, not in a technical way but in a *rules* way. We need to allow for RPMs built in non-traditional ways (the source git idea). No solution is forced to consume these, but we shouldn't block someone from providing them, either. For example, Silverblue may want to provide some Flatpaks that are built (in an open and transparent from-source way) straight to Flatpak rather than going through RPM. Or AI/ML may want to generate and ship container images with python wheels built specially. (https://github.com/thoth-station/tensorflow-build-s2i) 6. We need to relax policies on what Solutions are allowed to do. (We also want to drop the Spins/Labs naming thing — it's confusing to people even within the project. Note that Solutions is *also* not a great name. Feel free to suggest!) Solution-makers should know their audiences best and should be able to make more technical choices — the things currently known as Spins should be able to offer different defaults and presets, even including enabling different module streams by default. Solutions should not require Spin SIG (or FESCo) approval on technical merit or perceived feasibility. There are probably more, but these are the half-dozen that come to mind right away. -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader _______________________________________________ council-discuss mailing list -- council-discuss@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to council-discuss-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/council-discuss@xxxxxxxxxxxxxxxxxxxxxxx
