----- Original Message ----- > On Tuesday 29 of January 2013 17:29:47 pete wrote: > > Hey guys, > > > > I've been reading the Feature discussions on devel@ today, and an > > idea > > came to mind. A process for documenting accepted Features would > > help > > prevent major changes from slipping through the cracks. Here's what > > I > > came up with so far; I think we can hammer it into something > > useful: > > Hi Pete, > thanks for kicking this off - I've been overflooded with all features > coming and > I did not have time to start it (actually I had time, but mentally > ;-). > > At FUDCon we had a long discussion how the feature process should > look like > and the result is - we would like to do the real proper planning and > tracking > of features (so it will be Planning process, not feature process - > even we > could find some other name?) and split it from marketing side - so > only a > subset of these proposals will be featured (and thus it's the word > "feature"). Hi, I'm going to reopen this discussion again - with more details available now. FESCo agreed on the feature process revamp [1] - we are now trying to plan the release and actually separate the planning/tracking from marketing side. Features process is now going to be called Planning process (even I'm not sure we have ever call it Features process ;-) and feature will become "changes". And real features will be created based on the list of changes - it's the idea for now, looking for your - docs and marketing teams input. > > Accepted Features[1] will be listed in a table roughly analogous to > > that > > used for Release Note Beats[2]. The table would have columns for > > the > > Feature name, a docs volunteer, and developer contact, as well as > > others > > reflecting the Feature documenting workflow. > > Believe me - maintaining even FeatureList is a big pita - but > speaking about > tracking of development and splitting marketing - this could be done > on the > main FeatureList - I'm definitely open to any suggestions from > documentation > team how to enhance FeaturesList to work for you - as we really want > all > planning/tracking to happen in one place (and definitely not anything > that's > out of sync often etc.). So what I can offer you here - we could join the effort here, not to duplicate amount of the work. We are definitely going to change how feature pages will look, how feature list would look too and here I see an opportunity to have one common place. Btw. we (me/FESCo) are still thinking what tool to use, wiki is suboptimal for this task, ideas are Bugzilla, Trac (but I've already mentioned this in my first reply)... [1] https://fedoraproject.org/wiki/User:Mmaslano/Feature_process > Jaroslav > > > [1] > > http://fedoraproject.org/wiki/Releases/19/FeatureList#Fedora_19_Accepted_Fea > > tures [2] > > http://fedoraproject.org/wiki/Category:Documentation_beats > > -- > docs mailing list > docs@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe: > https://admin.fedoraproject.org/mailman/listinfo/docs -- marketing mailing list marketing@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/marketing
