On Fri, Dec 24, 2010 at 04:57, Arjan van de Ven <[email protected]> wrote:
>
> For MeeGo to have a chance of success, the amount of "paperwork" must at the
> very minimum be in proportion to the change you are making.. Right now this
> is waaaaaay off and this is turning away contributors. (I see this
> internally with people who want to contribute some small thing.. and then
> get their improvement rejected.. they go "WTF" and go back to working on
> some other distro instead).
Are these people who want to contribute one small thing going to be
given permission to directly push into the "trunk"; without any
oversight? Who's doing the patch review?
Typically in an open source project, someone wanting to contribute
some small thing would post a patch or a gitorious merge request.
Whoever takes that in (say you, Arjan) is responsible for ensuring it
"improves MeeGo". But also that it:
* Doesn't contradict any other features being planned for the next
release.
* Doesn't duplicate work being done elsewhere.
* Is conformant with standards.
* Provides a mechanism for vendors and release management to know
what's gone into a release at a functional-, rather than code-,
level.
As David pointed out, having every change to MeeGo being made relevant
to a Bugzilla/Featurezilla entry doesn't mean that every single change
needs a unique issue: bugs may have a number of changes; features
almost certainly will.
I'm reminded of an old knowledge management concept (all the rage in
the early part of the century ;-)). You can have:
o Bytes
o Bytes + meta-data = Data
o Data + meta-data = Information
o Information + meta-data = Knowledge
I'd say that gitorious/OBS provide information: who changed what, when
& how. The additional meta-data of a BMC entry provides you with *why*
- providing "knowledge".
To be honest, we have a similar process at work. Not discouraging
people wanting to improve the product in their spare time *is*
something we worry about as well. However, the use of issue tracking
makes this easier. If someone's got an idea they can get it logged
alongside all the "core" and "proper" features which are going on.
Being part of the same process means that their design can perhaps be
captured if they don't have time to polish the code; that someone more
core can be assigned to pick up on it; that workflow can be used to
ensure processes & procedures meet their requirements *without* being
overly heavyweight.
Cheers,
Andrew
--
Andrew Flegg -- mailto:[email protected] | http://www.bleb.org/
Maemo Community Council member
_______________________________________________
MeeGo-packaging mailing list
[email protected]
http://lists.meego.com/listinfo/meego-packaging
