On Dec 16, 2005, at 8:06 AM, josh giesbrecht wrote:
> Hi all,
>
> One quick sanity check: where do we want information to end up? Is
> the
> ALU Wiki used primarily to give us a repository for brainstorming, or
> are we putting more 'public' info there?
Let me start by saying that I'm incredibly impressed with David Aue's
work on the ALU wiki. It certainly brings home some of the strengths
of wikis. However I also have some reservations about trying to do
too much on a wiki. So let me explain what I understand the relation
between the www.lispniks.com website, the ALU Wiki, and the Common
Lisp Directory to be and how they all relate to the CL Gardener's
project.
* www.lispniks.com
I expect www.lispniks.com to be the main home for information about
CL Gardeners, what we're about, what projects we're working on, etc.
I prefer to keep the public face of CL Gardeners on a traditional
website because of my previously mentioned interest in the idea of
editorial control. Which does not mean (in this case anyway ;-)) that
I have any interest in exercising dictatorial editorial control--just
that I want it to be controllable by somebody. I'm highly
enthusiastic about the idea of people collaborating on pretty much
all aspects of CLG and will work hard to make sure that folks who
want to contribute can do so without a lot of hassle. For instance,
as I've mentioned before, I plan to set up a subversion repository on
www.lispniks.com which I'll use to manage the website's content and
I'll be happy to give commit access to folks who want to do
substantial work on the site.
I also expect to host some of the products of CL Gardener's projects
on www.lispniks.com. For instance, the FAQ will live there. This is
again in order to maintain some editorial control and also because
some kinds of information will be easier to present in an appealing
way with the full power of HTML rather than the subset provided by a
wiki.
* The ALU Wiki
The ALU Wiki on the other hand is an excellent place to do the kind
of digesting that David has been doing of conversations that happen
on the mailing list. Thus I think the ALU Wiki can be used as a tool
for interested folks to collaboratively develop a proposal for a CLG
project. I suspect these pages should have a short and standard
lifecycle--someone creates the page and puts up a strawman proposal
of what problem the project is aimed at solving. Then other
interested folks can refine the problem statement, add information
relevant to the problem (such as the comparison of IDE's on the
current Newbie Development Environment page), and come up with a plan
of attack. When the project seems reasonably well defined the folks
who want to work on it should send mail to the mailing list so the
project can be added to the official CLG Projects page on
www.lispniks.com and the ALU page can be deleted or kept as a shared
notebook for the folks working on the project.
* A digression
Which of course brings up the question of what it means for a project
to become an "official" CLG project. I'm inclined for there to be
some controls on that--I think it's important for the viability of
the CLG project as a whole that sub-projects that spin up under it's
banner meet some threshold of goodness, achievability, fitness with
the CLG philosophy, etc. This is particularly important now when we
are starting--I suspect a good portion of the existing Common Lisp
world that hasn't joined us is waiting to see what we're going to do.
If we come out of the gate with a few reasonable projects and
actually carry them through to completion then we'll gain a lot of
credibility. But if we immediately start running all over trying to
change the world and don't get anywhere we'll just look silly. Not
that I mind looking silly on principle, but eventually we're going to
want to take on projects that will require us to be in the good
graces of other folks such as implementors and library authors that
we want to collaborate with us. Anyway, this is probably worth some
more thought and some discussion.
Personally I'm inclined to follow something like the way Apache
Software Foundation projects work. To quote from: <http://
www.apache.org/foundation/how-it-works.html>
Decision Making
Projects are normally auto governing and driven by the people
who volunteer for the job. This is sometimes referred to
as "do-ocracy" -- power of those who do. This functions well
for most cases.
When coordination is required, decisions are taken with a lazy
consensus approach: a few positive votes with no negative vote
is enough to get going.
Voting is done with numbers:
* +1 -- a positive vote
* 0 -- abstain, have no opinion
* -1 -- a negative vote
The rules require that a negative vote includes an alternative
proposal or a detailed explanation of the reasons for the
negative vote.
The community then tries to gather consensus on an alternative
proposal that resolves the issue. In the great majority of
cases, the concerns leading to the negative vote can be
addressed.
This process is called "consensus gathering" and we consider it
a very important indication of a healthy community.
The only real question in my mind is how to identify the members of
the "do-acracy", especially now when we're starting out. In Apache
projects there's a distinction made between developers, committers,
and PMC (project management committee) members where only the latter
have votes that really count. While that seems a bit hierarchical, it
is also supposed to be based on merit. One becomes a developer by
actually submitting patches. Then one is made a committer by
nomination and vote of the PMC members. And PMC members get to decide
who else is a made a PMC member. I don't know if we need all three
levels nor how to get bootstrapped but I'm sure we could come up with
something. For instance, we could appoint Brad Beveridge the seed PMC
member since this was all his idea to start with and then he can
appoint a few new PMC members and then they can expand their ranks as
appropriate and start making folks committers as soon as I get the
svn repository set up and we have stuff to work on.
* Back to the ALU Wiki and also the Common Lisp Directory
Another relationship between the CLG and the ALU Wiki is that we can
act as Wiki contributors and WikiGnomes on the ALU Wiki. That is, the
greatest strength of a Wiki (in my experience) is when it is full of
well-organized, interesting content. Since there is currently very
little activity on the ALU Wiki it is sort of like a big grassy field
ready for planting with maybe a few interesting wild flowers already
growing in it that'd be worth keeping and building a garden around.
Folks who are interested in researching various aspects of the Lisp
world (e.g. what libraries are available to do X?) and writing about
it should definitely consider contributing to the ALU Wiki. And if
that takes off, hopefully the more experienced Lispers on this list
will also take a look and do some WikiGnoming to keep things on an
even technical keel. Certainly a vibrant and well-maintained Lisp
wiki would be a pleasant addition to the Lisp landscape.
Similarly, I see the Common Lisp Directory as a project that CL
Gardeners may be interested in helping out with. I'm hoping Marc
Battyani will write something about what kinds of things folks could
help out with to make it a useful resource so we can see if it's
something folks are interested in working on.
Anyway, that's probably enough for now. Let me know what you think.
-Peter
--
Peter Seibel * [EMAIL PROTECTED]
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
_______________________________________________
Gardeners mailing list
[email protected]
http://www.lispniks.com/mailman/listinfo/gardeners
