[wiki curation] Feature template

Mike Kolesnik mkolesni at redhat.com
Wed Jan 15 12:56:22 UTC 2014


----- Original Message -----
> Hi Russ,
> 
> On 01/14/2014 07:53 PM, R P Herrold wrote:
> > On Tue, 14 Jan 2014, Dave Neary wrote:
> >> {{Feature|name=Network QoS|modules=network|version=3.3|status=Released}}
> > 
> > Three additional suggestions:
> > 
> > Isn't there a need for way to see:
> > 	Appeared at
> > 	Stable by
> > 	Retired after
> 
> I would suggest no - perhaps a "deprecated" field would be useful, but
> I'm unaware of any feature which was added then later removed from the
> project.
> 
> There may be a use for a "Proposed" status - that is, the feature page
> exists, but no-one's stepped up to code it yet - and an "Owner" field,
> so that we can identify the primary developer of the feature.
> 
> > As I read setup articles in the wiki, there seems to be such a
> > life-cycle
> 
> Set-up articles are slightly different - we will continually try to
> improve and streamline the installation experience. But they wouldn't
> come under "Feature pages" for me.
> 
> > 2. Also, exposing:
> > 	Last edited on:
> > 	Last editor:
> > 
> > would be a goodness -- I regularly receive direct email from
> > folks not willing for wnatever reason to wade into a high
> > volume mailing list, but seeking help, and having the ability
> > to ** find ** someone, anyone authoring in a subject matter
> > area is part of the FOSS ethic
> 
> Yes, I think an "Updated on:" field would be good. In combination with

Wouldn't this be the same as the "last updated" field that we already have in the feature pages?

> an "Owner" field, that should take care of your need.

We have an entire "owner" section in the feature pages as well..

> 
> > 3. And having a formal machanism to formally catch
> > 	Potentially stale:
> > 
> > content, so that pages might be marked in one pass and 'on the
> > fly', then later searched, and finally curated back to not
> > 'Potentially stale'
> > 
> > were markings I used when maintaininthg CentOS wiki presence,
> > to combat entropy
> 
> Again, it seems like you're thinking of this as something which might be
> on all pages - its specifically for "feature pages" - they are
> functional specs and design documents for features to be added to oVirt.
> I don't think "potentially stale" applies (perhaps I'm wrong?).
> 
> Cheers,
> Dave.
> 
> --
> Dave Neary - Community Action and Impact
> Open Source and Standards, Red Hat - http://community.redhat.com
> Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 



More information about the Arch mailing list