Dne 7.12.2012 11:13, "Jóhann B. Guðmundsson" napsal(a):
On 12/07/2012 09:28 AM, Vít Ondruch wrote:
Feature is something somebody considers important enough to create
feature page for it. Period.
That describes the current state and is your point of view.
To me an "Feature" is a completely different thing.
Could you be more specific please?
I am not sure why do you want to categorize it by size and impact,
when it will be autocategorized by feedback on ML.
It's common knowledge that you cant autocategorized by feedback on
Mailing list regardless what's it's for. ( For obvious reasons )
They are probably not so obvious to me. But I can imagine several types
of responses on ML:
1) No response at all. This is positive, since the feature was probably
discussed on different places previously, such as SIG ML or is
non-controversial.
2) Positive response. Everybody probably agrees that Gnome 3 should be
updated in next release.
3) Controversial feature, such as /tmp on tmpfs
4) Only negative feedback. E.g. lets move to yet another init system.
5) WTF feedback. Why are you even proposing this minor update of this
unknown library as a feature (but this is non-category, since it will be
probably rejected by Package Wrangler already)?
These are 5 categories of features I can imagine. Now please tell me if
the categorization is not clear and if that is not obvious how to
proceed with these.
The only think matters is that the Feature is widely advertised and
that the community can provide early feedback.
No that is not enough because in the end you will only get feedback
from users of those feature not necessary from developers of other
components that might get affected by that feature.
Yes, nobody never cares until it is not late. I can't change that. But
I'm trying. Announcing features in devel/devel-announce is definitely
step in good direction.
Please avoid bureaucracy. I would realy hate to see something like
FFCo (Fedora Feature Committee), which would decided if feature is
feature, major change, alteration, evolution or disruption, since it
really doesn't matter.
FESCO is for that, as in to accept,decide and determine the wider
impact an feature might have to the whole projects eco system and
arguably the entity that's responsible for it to be integrated into
the distribution in as painless manner for users and developers alike.
( from my pov ).
FESCo's responsibilities does not change at all. The benefit will be
that FESCo will be able to spent more time paying attention to features
that are worth of attention. Don't forget that this discussion is
initiative of FESCo members, who feels to be overwhelmed by
non-important features, not mine.
Vít
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
