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?
Regards,
Erik