[melbourne-pug] Group Project summary and ideas

[Peter Galaxy]

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 
mini-meetings. 

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 
presentations)
- 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 
(October) 
- 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...
URL: http://mail.python.org/pipermail/melbourne-pug/attachments/20050620/a1dc3c7a/attachment.htm