----- Original Message -----
From: "Erik Moeller" <erik_moeller(a)gmx.de>
To: <textbook-l(a)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(a)wikipedia.org
http://mail.wikipedia.org/mailman/listinfo/textbook-l