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* -- 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
