The Fedora Council met last week in Minneapolis, Minnesota. It’s a lovely city, but rather cold, so we largely stayed within the interconnected network of enclosed bridges known as the Skyway — and in our conference room working. One of our main projects was the draft below. This is a follow-on from our update to the mission statement last year. It represents the way the Fedora Council would like the Project to make that mission a reality — a guiding policy. We’d like wider community feedback on this approach (and the write-up of it), after which we plan to include the final version in the project documentation.
Fedora’s Mission ----------------
“Fedora creates an innovative platform for hardware, clouds, and containers that enables software developers and community members to build tailored solutions for their users.”
We do this within the context of the four foundations: freedom, friends, features, and first.
Context -------
The Fedora Council identifies the short-, medium-, and long-term goals necessary to keep the Project on the leading edge of technology. The Fedora.next initiative focused the outputs of the project around use cases. In 2017, we updated the mission statement to reflect changes in the computing landscape. Today, it’s too difficult to build new solutions in Fedora.
Our Approach ------------
We will make it easy for the community to build solutions, address specific developer problems, and meet their end users’ specific needs. We will do this by encouraging and helping Objectives which make the necessary changes required to ease the process. This accelerates the transformation of Fedora into a community that enables the construction of solutions.
Internally, Fedora focuses on enabling these solutions to be built. The outputs of Fedora are the Solutions our community members build. Our focus on enablement allows experimentation without prior judgement or gate-keeping.
What does this mean? --------------------
Teams such as Design, Documentation, Packagers, Release Engineering, and Quality Assurance provide building blocks and offer services to other community members and Teams. Services and building blocks include: CI infrastructure, community building advice and guidance, event funding, logo services, RPM or other software packages, swag, testing and validation, user support, or UX design.
Anyone may use Building Blocks like software packages and artwork to create a Solution. Solutions include: Fedora Workstation, KDE Plasma, and the Python Classroom Lab. Teams define criteria for services they provide to solution-builders. For example, teams providing press and promotional support may choose to provide additional support to Solutions with larger user bases.
Teams are free to define elements of their Solutions, such as intent, deliverables, and release cadence. Teams can build Solutions from any building block and pick and choose what tools they use. Based on their choices, they get different levels of ability to use the Fedora trademark (i.e. “Fedora Remix” vs “Powered by” vs Fedora”). Some solutions are the premier showcases that we call Editions; these are used in the gating tests for our releases.
On Tue, Dec 11, 2018 at 08:12:42PM -0500, Matthew Miller wrote:
The Fedora Council met last week in Minneapolis, Minnesota. It’s a lovely city, but rather cold, so we largely stayed within the interconnected network of enclosed bridges known as the Skyway — and in our conference room working. One of our main projects was the draft below. This is a follow-on from our update to the mission statement last year. It represents the way the Fedora Council would like the Project to make that mission a reality — a guiding policy. We’d like wider community feedback on this approach (and the write-up of it), after which we plan to include the final version in the project documentation.
Fedora’s Mission
“Fedora creates an innovative platform for hardware, clouds, and containers that enables software developers and community members to build tailored solutions for their users.”
We do this within the context of the four foundations: freedom, friends, features, and first.
Context
The Fedora Council identifies the short-, medium-, and long-term goals necessary to keep the Project on the leading edge of technology. The Fedora.next initiative focused the outputs of the project around use cases. In 2017, we updated the mission statement to reflect changes in the computing landscape. Today, it’s too difficult to build new solutions in Fedora.
Our Approach
We will make it easy for the community to build solutions, address specific developer problems, and meet their end users’ specific needs. We will do this by encouraging and helping Objectives which make the necessary changes required to ease the process. This accelerates the transformation of Fedora into a community that enables the construction of solutions.
Internally, Fedora focuses on enabling these solutions to be built. The outputs of Fedora are the Solutions our community members build. Our focus on enablement allows experimentation without prior judgement or gate-keeping.
What does this mean?
Teams such as Design, Documentation, Packagers, Release Engineering, and Quality Assurance provide building blocks and offer services to other community members and Teams. Services and building blocks include: CI infrastructure, community building advice and guidance, event funding, logo services, RPM or other software packages, swag, testing and validation, user support, or UX design.
Anyone may use Building Blocks like software packages and artwork to create a Solution. Solutions include: Fedora Workstation, KDE Plasma, and the Python Classroom Lab. Teams define criteria for services they provide to solution-builders. For example, teams providing press and promotional support may choose to provide additional support to Solutions with larger user bases.
Teams are free to define elements of their Solutions, such as intent, deliverables, and release cadence. Teams can build Solutions from any building block and pick and choose what tools they use. Based on their choices, they get different levels of ability to use the Fedora trademark (i.e. “Fedora Remix” vs “Powered by” vs Fedora”). Some solutions are the
Fedora Powered? :)
P
premier showcases that we call Editions; these are used in the gating tests for our releases.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ council-discuss mailing list -- council-discuss@lists.fedoraproject.org To unsubscribe send an email to council-discuss-leave@lists.fedoraproject.org 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@lists.fedorapr...
On Wed, Dec 12, 2018 at 5:36 AM Petr Šabata contyk@redhat.com wrote:
On Tue, Dec 11, 2018 at 08:12:42PM -0500, Matthew Miller wrote:
Teams are free to define elements of their Solutions, such as intent, deliverables, and release cadence. Teams can build Solutions from any building block and pick and choose what tools they use. Based on their choices, they get different levels of ability to use the Fedora trademark (i.e. “Fedora Remix” vs “Powered by” vs Fedora”). Some solutions are the
Fedora Powered? :)
In the past, we've occasionally discussed using this term for things like appliances built on Fedora. I can see this becoming more likely now that we have Fedora IoT Edition.
On Tue, Dec 11, 2018 at 8:12 PM Matthew Miller mattdm@fedoraproject.org wrote:
The Fedora Council met last week in Minneapolis, Minnesota. It’s a lovely city, but rather cold, so we largely stayed within the interconnected network of enclosed bridges known as the Skyway — and in our conference room working. One of our main projects was the draft below. This is a follow-on from our update to the mission statement last year. It represents the way the Fedora Council would like the Project to make that mission a reality — a guiding policy. We’d like wider community feedback on this approach (and the write-up of it), after which we plan to include the final version in the project documentation.
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.
Can we approach the topic a different way? Perhaps by saying what you believe needs to materially *change* to make this a reality?
josh
Fedora’s Mission
“Fedora creates an innovative platform for hardware, clouds, and containers that enables software developers and community members to build tailored solutions for their users.”
We do this within the context of the four foundations: freedom, friends, features, and first.
Context
The Fedora Council identifies the short-, medium-, and long-term goals necessary to keep the Project on the leading edge of technology. The Fedora.next initiative focused the outputs of the project around use cases. In 2017, we updated the mission statement to reflect changes in the computing landscape. Today, it’s too difficult to build new solutions in Fedora.
Our Approach
We will make it easy for the community to build solutions, address specific developer problems, and meet their end users’ specific needs. We will do this by encouraging and helping Objectives which make the necessary changes required to ease the process. This accelerates the transformation of Fedora into a community that enables the construction of solutions.
Internally, Fedora focuses on enabling these solutions to be built. The outputs of Fedora are the Solutions our community members build. Our focus on enablement allows experimentation without prior judgement or gate-keeping.
What does this mean?
Teams such as Design, Documentation, Packagers, Release Engineering, and Quality Assurance provide building blocks and offer services to other community members and Teams. Services and building blocks include: CI infrastructure, community building advice and guidance, event funding, logo services, RPM or other software packages, swag, testing and validation, user support, or UX design.
Anyone may use Building Blocks like software packages and artwork to create a Solution. Solutions include: Fedora Workstation, KDE Plasma, and the Python Classroom Lab. Teams define criteria for services they provide to solution-builders. For example, teams providing press and promotional support may choose to provide additional support to Solutions with larger user bases.
Teams are free to define elements of their Solutions, such as intent, deliverables, and release cadence. Teams can build Solutions from any building block and pick and choose what tools they use. Based on their choices, they get different levels of ability to use the Fedora trademark (i.e. “Fedora Remix” vs “Powered by” vs Fedora”). Some solutions are the premier showcases that we call Editions; these are used in the gating tests for our releases.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ council-discuss mailing list -- council-discuss@lists.fedoraproject.org To unsubscribe send an email to council-discuss-leave@lists.fedoraproject.org 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@lists.fedorapr...
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.
On Thu, 13 Dec 2018 at 15:06, Matthew Miller mattdm@fedoraproject.org wrote:
Lots of items redacted...
There are probably more, but these are the half-dozen that come to mind right away.
Each of those items themselves would need a LOT more explanation because anyone of them seems to be a major change which the Fedora community would normally take 1 release to get people to stop seething about, one to get interested in and one to iron out the kinks in.. Does each one have a 'champion' or two to help work through it? And how long before the longer explanations start showing up?
On Thu, Dec 13, 2018 at 03:19:55PM -0500, Stephen John Smoogen wrote:
Each of those items themselves would need a LOT more explanation because anyone of them seems to be a major change which the Fedora community would normally take 1 release to get people to stop seething about, one to get interested in and one to iron out the kinks in.. Does each one have a 'champion' or two to help work through it? And how long before the longer explanations start showing up?
7. We need to be able to adapt to the changing world without taking 18 months to do so. :)
In seriousness: I'm working on a summary post (which Ben Cotton kindly drafted -- thanks Ben!) for the whole meeting. Maybe that should have come first, but I got excited about the formalized ready-to-go document that we had. :)
On 12/11/18 5:12 PM, Matthew Miller wrote:
The Fedora Council met last week in Minneapolis, Minnesota. It’s a lovely city, but rather cold, so we largely stayed within the interconnected network of enclosed bridges known as the Skyway — and in our conference room working. One of our main projects was the draft below. This is a follow-on from our update to the mission statement last year. It represents the way the Fedora Council would like the Project to make that mission a reality — a guiding policy. We’d like wider community feedback on this approach (and the write-up of it), after which we plan to include the final version in the project documentation.
Fedora’s Mission
“Fedora creates an innovative platform for hardware, clouds, and containers that enables software developers and community members to build tailored solutions for their users.”
We do this within the context of the four foundations: freedom, friends, features, and first.
Context
The Fedora Council identifies the short-, medium-, and long-term goals necessary to keep the Project on the leading edge of technology. The Fedora.next initiative focused the outputs of the project around use cases. In 2017, we updated the mission statement to reflect changes in the computing landscape. Today, it’s too difficult to build new solutions in Fedora.
Yeah, I would agree, but also building new solutions is a lot of work, and people must be willing to do that.
Our Approach
We will make it easy for the community to build solutions, address specific developer problems, and meet their end users’ specific needs. We will do this by encouraging and helping Objectives which make the necessary changes required to ease the process. This accelerates the transformation of Fedora into a community that enables the construction of solutions.
Internally, Fedora focuses on enabling these solutions to be built. The outputs of Fedora are the Solutions our community members build. Our focus on enablement allows experimentation without prior judgement or gate-keeping.
How does this play off available resources? If say someone came along and wanted to make a solution where a bunch of the resources would need to be created (code, test plans, content), it would be up to that group wanting the solution to provide the work to do that? ie, some resources are much easier to hand over (disk space, cpu) and others are a lot of work (code, test plans, docs). I guess this is up to the resource provider how much they want to provide and at what point they say "sorry, you need to write that yourself"?
What does this mean?
Teams such as Design, Documentation, Packagers, Release Engineering, and Quality Assurance provide building blocks and offer services to other community members and Teams. Services and building blocks include: CI infrastructure, community building advice and guidance, event funding, logo services, RPM or other software packages, swag, testing and validation, user support, or UX design.
Anyone may use Building Blocks like software packages and artwork to create a Solution. Solutions include: Fedora Workstation, KDE Plasma, and the Python Classroom Lab. Teams define criteria for services they provide to solution-builders. For example, teams providing press and promotional support may choose to provide additional support to Solutions with larger user bases.
Teams are free to define elements of their Solutions, such as intent, deliverables, and release cadence. Teams can build Solutions from any building block and pick and choose what tools they use. Based on their choices, they get different levels of ability to use the Fedora trademark (i.e. “Fedora Remix” vs “Powered by” vs Fedora”). Some solutions are the premier showcases that we call Editions; these are used in the gating tests for our releases.
This all sounds fine to me, but is pretty abstract. Also, how are disputes handled? I guess they come to the council? If say, releng was happy with a 6 month cadence, but developers wanted faster?
Would it be possible to work up an 'example team' showing how to document this or perhaps someone could write up what the _current_ blocks and solutions and elements are for the existing teams? I'd guess each team would have to write up something and each 'solution' would also need to write up something with all this spelled out? And solutions would use elements, a, b, c, and make their own d, e, f? Or could they only use existing elements?
I'm somewhat at a loss how to do this for the two teams I am most involved with (infrastructure and releng). More guidance would be nice.
kevin
On Thu, Dec 13, 2018 at 11:04:47AM -0800, Kevin Fenzi wrote:
How does this play off available resources? If say someone came along and wanted to make a solution where a bunch of the resources would need to be created (code, test plans, content), it would be up to that group wanting the solution to provide the work to do that? ie, some resources are much easier to hand over (disk space, cpu) and others are a lot of work (code, test plans, docs). I guess this is up to the resource provider how much they want to provide and at what point they say "sorry, you need to write that yourself"?
Yeah, I think that last thing is pretty much how it should work. After all, you can't create resources for work just by wishing for them (oh, if I could!), and you can't make a volunteer community volunteer. What we'd like to see is for service providers to provide a set menu of options, and for each option give a set of requirements. For example, perhaps Mindshare will fund release parties up to $150 for the release of *any* formally defined solution, but offer $500 for solutions with a user base above NNN as determined by Fedora metrics. Websites might offer a pre-canned website to anyone with downloadable release artifacts (isos or qcows or whatever), and offer some customization services to solution teams with an organized team which meets at least every other week.
We'd actually started to more formally define some pre-set labels and example services, but that fell into "naming things is hard" pretty quickly. And, we don't necessarily want to give the impression that there's a hierarchy that all solutions need to climb. For some things, serving a niche use case very well is exactly right.
This all sounds fine to me, but is pretty abstract. Also, how are disputes handled? I guess they come to the council? If say, releng was happy with a 6 month cadence, but developers wanted faster?
There's a separate assumption that we want release engineering to allow people to release their own solutions pretty much at will. There will be a base Fedora OS release -- possibly a "base OS" smaller than current all-the-RPMs -- which will have an underlying cadence (probably still six months), and that's a fundamental we expect a lot of solutions to build on. This is stuff for the Lifecycle objective to figure out.
Would it be possible to work up an 'example team' showing how to document this or perhaps someone could write up what the _current_ blocks and solutions and elements are for the existing teams? I'd guess each team would have to write up something and each 'solution' would also need to write up something with all this spelled out? And solutions would use elements, a, b, c, and make their own d, e, f? Or could they only use existing elements?
Yes, that's definitely the idea. Providing an example is a good suggestion. In fact, the Council could do this for some of the things we do directly, like providing Hackfest funding.
I'm somewhat at a loss how to do this for the two teams I am most involved with (infrastructure and releng). More guidance would be nice.
*nod*
council-discuss@lists.fedoraproject.org
-
Josh Boyer -
Kevin Fenzi -
Matthew Miller -
Petr Šabata -
Stephen Gallagher -
Stephen John Smoogen