[Textbook-l] No new wikis

[Sanford Forte]

----- Original Message ----- 
From: "Erik Moeller" <erik_moeller at gmx.de>
To: <textbook-l at wikipedia.org>
Sent: Saturday, July 19, 2003 12:46 AM
Subject: Re: [Textbook-l] No new wikis


> Daniel-
> > Erik wrote:
> >> The fundamentals of the [textbook] project (what
> >> kind of material is to be placed there; do we need
> >> a textbook project or should it be part of a larger
> >> project) were not discussed much,
>
> > What kind of material? I don't understand that part of your statement. A
> > textbook is a way to organize non-fictional information in a way that
can be
> > used to lead a student through that information. Given the vast number
of
> > courses we could make textbooks for I fail to see how that is too
specific.
>
> As I already said, there's a lot more non-fictional material that does not
> meet the definition of "textbook", but the creation process of which
> nevertheless shows sufficient parallels with the authoring of textbooks to
> warrant inclusion in a common project.
>
> >> the specifics (how to write textbooks NPOV etc.)
> >> were discussed in great detail. I don't remember
> >> a timetable or a deadline for suggestions ever
> >> being brought up.
>
> > ? Was there for Wikipedia? This type of micromanagement can kill
volunteer
> > projects.
>
> A timetable is micromanagement? Boy, you should read more Dilbert :-). A
> timetable is essential for allowing all potentially interested parties to
> voice concerns and suggestions before something goes live and it becomes
> difficult to revert certain decisions that have already been made.
>
> >> But what about HOWTOs and manuals of all
> >> kinds?
>
> > Why not? That seems similar enough for me. I think you are reading too
much
> > into the temporary name of the project.
> ...
> > Symantics. Wikipedia is far more than just an encyclopedia too
>
> "Encyclopedia" is a vague enough term to fit almost anything into it that
> we want; "textbook", on the other hand, refers to a quite specific type of
> work. I think this should be changed. Semantics are important -- the
> semantics we define now will be the foundations for policies and
> conventions that develop later.
>
> > ? Why the Wikipedia.org sub-domains? I already own wikibook.org/.com
>
> That seems like a reasonable project name to me. But please, no further
> names that are bastardizations of the word "wiki" like "Wiktion". These
> really don't work well in other languages.
>
> > If the needs of a particular project require separation then let's
provide
> > it. Having a project that is so broad that is has no focus is also a
realy
> > bad thing (Everything2 plays that role already).
>
> Obviously. Combining non-fiction and fiction on the same site would be a
> bad idea, for example.
>
> Discussing things on Meta:
> > Partly true - the WikiProjects always use at least one real article as a
> > test case but then many modifications are made as that template is
applied
> > to other articles - the template evolves. But a WikiProject is a far cry
> > from a new Wikimedia project (which has a vastly larger focus).
>
> Sure, but I fail to see how the discussion of a substantially larger
> project would somehow "overtax" Meta. The number of changes on Meta is
> only a fraction of those on the English wiki, and yet, the English wiki
> still scales. What's the problem with planning these things in an
> organized way?
>
> > Different strokes for different folks. Some people like chaos and
newness -
> > let them work out the rough spots and you can join later when the
project
> > has more or less stabilized.
>
> And stabilized to what? A chaotic process does not always lead to good
> results. It is better to at least define the ground rules before starting
> the project.
>
> > That wasn't my point - in fact I agreed that some discussion is a good
> > thing. But I am a bit skeptical that we need to have so much of the
ground
> > work settled before actually working on the project. Too much planning
for a
> > project is like the birth of Athena in which she sprung forth from the
head
> > of Zeus fully-grown, educated and in full battle armor - what a
headache.
>
> Just the basics:
> 1) Name of the project
> 2) Types of content that are to be covered
> 3) Key policies
> 4) Timetable for setting things up
> 5) Potential changes that need to be made to the software
> 6) Templates
> 7) Internationalization
> 8) Participants
>
> Formalize these things, then have a vote on whether the project should in
> fact be started. Is that too much to ask?
---------------
This is also good advice. Extrapolating from my last post (to Daniel),
Erik's points (above), along with frameworks (as content guidelines), would
be a good place to start any textbook project. The only quibble I have is
with 'timetable'. A timetable will help to create a sense of urgency; it can
be set up to remind people that a project has a 'delivery' deadline, while
at the same time leaving the door open to anyone who wants to contribute
past the deadline, as long as they understand that post-deadline
contributions will remain unofficial addendums (while being completely
useful to users who don't mind dealing with the dynamic nature of a
theoretically open-ended textbook project, as far as time is considered)

Sanford

> Regards,
>
> Erik
> _______________________________________________
> Textbook-l mailing list
> Textbook-l at wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/textbook-l