Forum OpenACS Q&A: Re: OpenACS Core Team Selection Issues

Collapse
Posted by Frank N. on
OK, this may drive this thead out on a tangent, but here goes...

Talli (PBC, s-o ZtA, b-o HtR),

You touch some important points, especially the part about the community sometimes having a closed feel. Both you and I have personally met many of the core people, so I suspect you agree that in reality the people behind are anything but closed to outsiders.

IMHO the problem is simply, that A) many of the core people know each other very well from the aD days, and B) they are often very, very busy as well. So I wonder if many of them simply have less of a need for making noises as compared to, say, a project, which historically grew out of a personal code project on the web. And when they do communicate, it is often in private. I'm a "recent addition" to the community :), and indirectly I can see that currently at times decisions are made, which are often only mentioned in passing in public at a later date, if at all.

Some ideas:

***) Have a weekly, or bi-weekly, "OpenACS Happenings for Week X-Y" thread on the dev forum. Here everybody are encouraged to tell what they are currently working on, decisions made (whether personal, or by, say, the OCT), and future plans. This would be easier to make and maintain than an official newsletter or the like. My guess is that even very brief entries by many of the core persons would show a flurry of activity, which often isn't apparent by reading the, at times, very quiet forums.

***) Have 'commit levels' and a document describing them. By this I mean some agreed upon policy of what people with commit priviledges but different levels of experience are allowed to do to the tree without asking anyone else (would perhaps help on the bug/patches issue). Eg. I am a newbie, so I am only allowed to change things in HEAD, that doesn't touch security issues or change the state of the DB. But I would be encouraged to fix, say, trivial noquote bugs where I find them, in cooperation with the package maintainer.

The OCT members are at the top, and then there might be two other levels, one in between newbie committers and the OCT, and those people without commit priviledges.

This way people 'down on the floor' would perhaps feel more free to work together closing the simpler bugs while sparing the core members. It might take twenty times as long for me to fix a DB select as one of the core members, but it would be educational, and I would get more of a feel of doing something constructive. It is a curious but well known psychological fact that you tie people more strongly to you by getting them to do favours for you, not the other way around!

***) We already have some pages on openacs.org aimed at the newcomer. After rereading them I cannot help feeling we might want to roll several of them into one, longer 'Getting Involded' document. Sort of a 'Welcome to the community, here is how it works and the pieces fit together' piece. Especially important would be a suggested list of reading (in order) and how to get started from scratch/proceed from here. Ie. this document should have a status of being wrapped in virtual neon saying 'README.1st'!

Also strongly emphasize the importance of the IRC channel, especially for newcomers, as this is a very good way of getting the feel of the other active people there. Yes, the IRC channel is mentioned twice on the front page already, but... ;)

The current documents seems to suggest that people, who try out OpenACS already have a fixed goal in mind, ie. they already know they want to build a website using the toolkit. The interested hobbyist who just stopped by may not have any such thing in mind.

***) Have mentors/IRC anchor people, who have publicly stated they don't mind be borthered by newbies. I am aware that in principle this is probably true for most of the long time community members, yet often I myself am reluctant to raise one of the core on, say, IRC over what may or may not be a trivial issue. Allow same mentors to step down from the position, temporarily or permanently, as time restrictions dictate.

Frank.

Collapse
Posted by Lars Pind on
Frank, this is a tangent from the voting issue, but you're absolutely right.

I could definitely see a newsletter happening if someone would volunteer to ping me and any other developer, say, every week or every other week to ask what I was up to, and then compile the list and post it somewhere.

I could see it happening in other ways, too, but I think that would be a good way to get it off the ground.

The "here's how you get involved" doc is important, and I encourage you and others to start compiling that as well. I have some thoughts, but I think it's best if a recent newcomer takes the time to write the "what I wish I'd found in a document when I started" document.

Mentor: Also yes.

There are many great ideas, we just need to pick some and make them happen.

/Lars

Collapse
Posted by Joel Aufrecht on
Back to how we can select an electorate for the upcoming election.

We have 24 committers. This pool is both too small and not inclusive of non-coders.

If we want to count everybody who's posted in the last three months, how many people is that? We have about thirty new posters per month, 130 different people post every month, and we have around a thousand posts a month. So we could pick an electorate size, such as 100 people, and then choose the cutoff that comes closest to that number. I.e., at least one post in the last three months would probably get hundreds, two posts in the last three months might get a hundred. (recent posters)

Should we then email all of these people to tell them that there's an election? What kind of turnout could we expect?

How will we nominate candidates? Is the potential candidate pool the committers, the electorate, or anybody? Can people put their own names up? Must nominations be seconded before names show up on the ballot?

How long is the election? 48 hours?