Fedora Board Recap 2009-12-17 UTC 1700

[John Poelstra]

William Jon McCann said the following on 12/19/2009 01:13 PM Pacific Time:
> People should step forward on their own, I agree.  Similarly I'd like
> the folks on the board go on the record and state publicly what parts
> of the proposal that they disagree with.  That would help me
> understand where the points of disagreement actually are.  Because
> those folks didn't bring up specific issues at FUDCon, on the list, or
> in the board meeting.
>
> But let's try to turn this into something positive.  For those of us
> who would like to see the board give an opinion on this issue - or for
> the project as a whole to move in this direction, what does the board
> recommend that we do at this point?  I have tried to convey that this
> wiki does not only represent my professional recommendation for the
> project but an effort to reflect the desires of many other
> stakeholders as well.  I'm sorry if this has appeared to be in bad
> form.  Even if it was I'm not sure it is productive to focus on that
> now.
>

https://fedoraproject.org/wiki/Desktop/Whiteboards/UpdateExperience

Overall I really like the "whiteboard."  I think it is a good collection 
of a lot of things that if implemented would make Fedora much better.

While this page is a collection of lots of good information I do not see 
it as a "proposal." To me it is more a laundry list of all the things 
that should be changed.  There is a section called "requirements", but 
these seem like more wide ranging policy changes that would affect a lot 
of different groups.  While many of these requirements or "changes" 
would be good for Fedora the part missing for me is how and when they 
would all be implemented.

For it to be a considered a proposal (that I as a board member would 
vote in favor of implementing), I would want to see a detailed section 
explaining the phases and process that these changes would be 
implemented with.

I would also suggest breaking the suggested changes into sections or 
separate pages by functional areas.  For example, FESCo, QA, Release 
Engineering, etc.  Some of the suggested changes might be implemented by 
enhancing the release criteria. Other changes might be implemented 
through policies created and monitored by other groups.

So in summary, there are lots of good ideas that would really benefit 
Fedora, but the list is somewhat overwhelming and the implementations 
details and related ownership and accountability for each individual 
item are ambiguous.

It would also be helpful to be clear about why this set of problems 
needs to be solved and what target audience we are intending to benefit 
by solving them.  I think this write-up assumes that a particular target 
audience would benefit from these changes, but that target audience is 
not clearly spelled out.  Doing so would make the case for these changes 
stronger.

John