Becoming a Steward
Last updated at 12:57 am UTC on 17 January 2006
Folks interested in becoming a Steward need to pipe up on the Squeak Mailing Lists to volunteer. The Guides will guide the rest of the Squeak community in evaluating candidates for stewarding a given package. The Guides will give the final go-ahead.
The Stewards for Packages page will record folks that have gone through that process and been approved.
A (partial) mail about stewardship
Date: Fri, 14 Feb 2003
From: Daniel Vainsencher
To: The general-purpose Squeak developers list
Ned Konz wrote:
> I think part of the problem now is one of ownership. As we transition to the new model – a model in which more and more of the image we know now gets separated into loadable packages – I think it's going to be extremely important to get people responsible for each package.
> Once there's someone to point to, and an identifiable artifact, I think it's easier to get documentation done.
I think ownership is critical for documentation, but it's even more important for something else most of us are really complaining about, though we call it documentation – conceptual integrity. When things are built piece-meal, by a number of people, each with their own slant on the ideas, names aren't consistent. The rules of the framework ARE sidestepped. An owner is there to mediate such things – always explaining why things are done in a certain way, adapting code to fit before accepting it into his package, and so forth.
People, we need owners, soon (maybe stewards is a better name, since the the code is actually free). I'd like to take a shot at a few misconceptions there may be about stewardship, and maybe plant a few ideas about how it should be:
- The steward is nobody's bitch. She's not someone you complain to, she's someone you bring an offering of feedback or code, and look to for wisdom. If you treat her any less nicely than you'd like to be treated in her place, she might stop.
- Becoming a steward isn't about having one bright idea, it's about having a stake in the thing. Submit patches for it. Answer questions (it's also a good way of getting mastery over details you've overlooked). Learn why it was written as it was, and document it. Never stop. Somewhere along the way, you become it.
- Being a steward is usually neither solo, nor a group effort. There's usually one person or tight group actively in charge of something. Otherwise it's hard to make those in or out decisions. But single people have limited perspective, and they eventually move on – that's why it's important to cultivate the people that sit on the periphery of some code. The people that mostly use, but occasionally submit a patch. Even if it isn't good enough to include in your package, help them maintain it for themselves in parallel, and maybe include it when it is good enough... you never know where your replacement will come from.
And even if the steward isn't someone that will automagically solve all your problems, it's the only way that the package system will ever do any of us any good - it'll allow more people to be involved in this process, and share the results.