[melbourne-pug] Group Project summary and ideas
qubero at gmail.com
Mon Jun 20 04:40:28 CEST 2005
I'm between ISPs right now so I don't get to check my email every day, so
I've just been reading through this list's posts. Here's a summary about
what people have said on doing a group project:
There is debate about whether the PUG meetings should be centred around the
group project, or where the group prpoject should be put asside to
There is also debate about whether to have sprints on many projects or to
have fewer (one?) long running projects.
And whether to continue an existing project (leveraging peoples existing
projects, but perhaps giving less satisfaction to others) versus a totally
new project (possibly reinventing the wheel)
And how to choose to a project that is inclusive of everyone (and doesn't
scare people away) or whether to specialise (away from the main group).
Maybe i inferred that last one rather than read it is a post. But anyway.
Okay, now for the "how do we solve these issues?" bit.
Firstly, we need to acknowledge that the reasons for joining the Python
Users Group are diverse. People come to learn new skills, learn more about
their own areas of interest, socialise, trade obsolete hardware, yada yada.
So why do we want to start a group project? to get some hands on experience,
work in a group, learn skills, satification of making something, and maybe
to write a driver for that 8 inch floppy drive with a Z80 controller.
So the goals of a group project aren't so radically different from the goals
of the PUG in general. But still people are scared to spend precious time
hacking together some useless code with some know-nothing geeks who don't
understand the first thing about reloading microcode on System/370
Mainframes of 1967.
So what can be done?
Make the group project a part of, but not the central part of, PUG meetings:
- Have a couple of people give lightning talks (5-10 minutes) on their pet
projects or proposals one month (July if people are ready: after the main
presentation. Could go on for a number of months if there are enough
- Have a 10 minute attempt to meet consensus on which project(s) we'd like
to take up as a group (August)
- Spend 5-10 minutes organising people, times, places and coding schedules
as well (August or Sept? which can be taken into email if it goes too long)
- Organise a sprint to get people involved, to be run after the main meeting
- and have a full presentation from the group when there's something to
present. (Aim for March)
If anyone would be scared away by 10-20 minutes of the meeting being taken
up by lightning talks and sceduling, please say so. I don't see any reason
why a group project would need to be the central part of PUG meetings, and
at the same time it doesn't need to be totally seperate. Likewise for
sprints vs long-term, there's no reason we can't do it both ways.
The main issue that I see is finding a project broad enough that enough
people can bring their own skill to it, and interesting enough that people
will be willing to make a commitment. The main ideas proposed so far are
PyPI (Richard Jones) and Centipyde (Maurice). I don't know much about either
so I'd like to see Richard and Maurice "volunteer" to give short (5-10
minute) presentations on these projects in July or August if they're willing
and able, along with anyone else who has ideas. I'd like to see us make the
group project a part of, but not the central part of, PUG meetings.
Peter (Pengo) Galaxy.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the melbourne-pug