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