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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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
