Fwd: [CAPRA Development] GeoNode community process
- From:
- Sebastian Benthall
- Date:
- 2010-05-11 @ 15:27
Forwarding this over to the public list.
Thanks for these recommendations, Andreas. I'm convinced!
Are there any objections to them? If not, I say we make them official.
I'll document things on Trac, contact Stu about the PSC, and try to work
towards clearer definition of modules and milestones.
---------- Forwarded message ----------
From: Andreas Hocevar <ahocevar@opengeo.org>
Date: Wed, Apr 28, 2010 at 5:01 AM
Subject: Re: [CAPRA Development] GeoNode community process
To: capra-dev@lists.opengeo.org
Hi,
On Apr 27, 2010, at 17:47 , Sebastian Benthall wrote:
> As some of you may have heard, its looking likely that there will soon
> be a non-OpenGeo person working on GeoNode. The World Bank wants to
> hire a developer to work on it full-time, so that that developer can
> be more responsive to their needs and and be an additional resource
> working on the software.
>
> It's not clear whether this person will function as a part of our team
> or will be an independent member of the developer community. But as
> more developers get involved in GeoNode (there are some IT people at
> GEM who are also interested), it's going to be important for us to
> figure out our community processes.
If more people get involved, we need a clear roadmap of not-yet implemented
features. I think our milestones are good enough, but maybe some ticket
descriptions need to be clearer than they are now, if others should be able
to take them on.
> Big open questions for me:
> * How should the team approve others to have commit access?
2-3 patches, to be reviewed by existing team members. If these patches prove
an understanding of the code base and coding skills, a team member can
propose to give that person commit access. If there are no -1 votes of other
team members, commit access can be granted.
> * Should we require that all patches get reviewed before they are
committed?
Not in the current stage of the project. It would slow down our development
pace. But we should do that once we have reached a stable, fairly feature
complete state of the code base.
It is the responsibility of each team member to make sure that things do not
break. This will work better if we define modules (e.g. GeoExt mapping
frontend), with one team member being responsible for each module. Other
developers participating in the development of a module can contact the
module manager and should be encouraged to ask for a review if in doubt
whether things could break with their changes.
> * Should we establish a steering committee?
Yes, and Stu should be a member of it - he pays, so he should have a chair
with decision making power. Other than Stu, I think Seb and David should
also be PSC members. I guess a small PSC is better than one that consists of
almost all developers.
> I'm interested in hearing from all of you on this because we have
> diverse experiences working with open source projects and communities,
> and it seems like these community decisions could be both challenging
> and critical.
The above is to be seen as my 2ยข.
-Andreas.
>
> --
> Sebastian Benthall
> OpenGeo - http://opengeo.org
>
>
> --
> Archive:
http://lists.opengeo.org/capra-development/archive/2010/04/1272383263473
> To unsubscribe send an email with subject "unsubscribe" to
capra-dev@lists.opengeo.org. Please contact
capra-dev-manager@lists.opengeo.org for questions.
--
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.
--
Archive:
http://lists.opengeo.org/capra-development/archive/2010/04/1272445271016
To unsubscribe send an email with subject "unsubscribe" to
capra-dev@lists.opengeo.org. Please contact
capra-dev-manager@lists.opengeo.org for questions.
--
Sebastian Benthall
OpenGeo - http://opengeo.org