[Compcomm] The Next Step
Guillaume Seguin
guillaume at segu.in
Tue Apr 17 16:32:42 EDT 2007
Planets are nice :) And it's something very very pleasant for users
Regards,
Guillaume
2007/4/17, Will Farrington <kalmwave at gmail.com>:
> Please note the concept of a "WRITE" team would be completely redundant
> if the proposal for a Planet Compiz in the admin ML gets off the ground.
>
> On Tue, 2007-04-17 at 15:28 +0100, Mike Dransfield wrote:
> > RYX wrote:
> > > The WEB-team focuses on the website-discussion and -improvement, the
> > > COREDEV-team focuses on improving the core (they even have their own
> > > list already and I think this works well), the PLUGDEV-team focuses on
> > > porting/improving/inventing old/new plugins, the APPDEV-team creates a
> > > settingsTool/pluginIfaceForDecorator/startupManager, the DOC-team gets
> > > its ass up and writes down good developer/user-documentation ...
> > >
> > >
> >
> > Just a note about these. I do not think its a good idea to
> > categorize devs like that. Really most people will have little
> > to do with core development. Its only really needed when we
> > need extra features for plugins or there is a bug.
> >
> > I think these teams would be good
> >
> > DEV - Should have actually written something substantial, not
> > just people who would like to do something one day (sorry, no
> > offense anyone), could be anything.
> >
> > WEB - Wiki, forum design etc. These people may also be responsible
> > for sysop stuff like restarting server or this could be another team.
> >
> > RELEASE - We BADLY need people to write about new releases and
> > publicise them. We need at least one person who is mildly technical
> > to translate the git logs into something people can understand. This
> > then needs to be put on a nice html page and linked on the usual
> > sites. There should also be someone mildly technical who can actually
> > prepare a tarball for release along with each compiz release.
> >
> > DOC - Sounds good, should clarify what is being documented though,
> > I assume the same people documenting the source code will be different
> > from those documenting how to install a deb.
> >
> > TEST - These people should routinely and systematically test new
> > releases for new bugs and confirm old bugs are fixed. People could
> > choose 1 or 2 plugins each and then design a test with the developer
> > which they can then repeat.
> >
> >
> > _______________________________________________
> > CompComm mailing list
> > CompComm at Rock3d.org
> > http://www.ubaight.com/mailman/listinfo/compcomm
>
> _______________________________________________
> CompComm mailing list
> CompComm at Rock3d.org
> http://www.ubaight.com/mailman/listinfo/compcomm
>
More information about the CompComm
mailing list