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