Documenting Features

[Jaroslav Reznik]

----- 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 at lists.fedoraproject.org
> To unsubscribe:
> https://admin.fedoraproject.org/mailman/listinfo/docs