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.
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.
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.
These are not textbooks. Yet, the two have similarities in style, and both are at least in part procedural knowledge.
I agree and would like to add that much of the current "How-tos" in Wikipedia should be moved.
The name "textbook" usually implies use in an educational setting. Yet much of the material that is currently there is also of interest outside such use.
Symantics. Wikipedia is far more than just an encyclopedia too (it is also an almanac and gazetteer; not to mention an encyclopedia of encylopedias). Same goes for Wiktionary (which is also a thesaurus, and translating dictionary).
IMHO "textbook" is too limited. It only encourages the creation of yet another spin-off project in the near future for other types of non-fictional works.
Like what? I already mentioned that how-tos can be reformatted into courses/textbooks. Big deal. We instruct = Wikinstruct (possible name that doesn't include "textbook").
What I would prefer is a structure like this:
encyclopedia dictionary non-fictional works (books.wikipedia.org) fictional works (tales.wikipedia.org)
? Why the Wikipedia.org sub-domains? I already own wikibook.org/.com and that can be used for any miscellaneous project that is in book form (that is, any project requiring a specific overall organization for each of its books). Wiktion might be a fun name for a wiki fiction project (or else it goes at fiction.wikibook.org).
....And a place to write all types of non-fictional works may be better than just a place to write textbooks -- the procedures for writing textbooks are in part specific, but in large part also applicable to writing other non-fictional works.
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).
Many templates we successfully use on the 'pedia were worked out that way.
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).
I have nothing against a little chaos, but Wiktionary had far too much of it for my taste. The chaos and ugliness on Wiktionary, the lack of any real leadership was what discouraged me from working on that project.
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.
Can you name a single idea that would not benefit from prior discussion?
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.
I prefer a more organic approach in which the rules are made based on actual experience on what does and does not work. Yeah, of course, some basic parameters should be decided before that but those should be minimal.
--- Daniel Mayer (aka mav)
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
----- Original Message ----- From: "Erik Moeller" erik_moeller@gmx.de To: textbook-l@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:
- Name of the project
- Types of content that are to be covered
- Key policies
- Timetable for setting things up
- Potential changes that need to be made to the software
- Templates
- Internationalization
- 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@wikipedia.org http://mail.wikipedia.org/mailman/listinfo/textbook-l
Erik Moeller wrote at last:
Just the basics:
- Name of the project
- Types of content that are to be covered
- Key policies
- Timetable for setting things up
- Potential changes that need to be made to the software
- Templates
- Internationalization
- Participants
Formalize these things, then have a vote on whether the project should in fact be started. Is that too much to ask?
Why hold a vote? If some people want to do it and others don't, then some people will do it while others won't. To be sure, there must be coders in the group that wants to do it, or it still won't get done! -- but if a group of coders wants us to vote to decide what they will do and what they won't, then they can do so.
Otherwise, I agree, with the understanding that some things may be incomplete before starting. Templates are the best example of this.
-- Toby
Toby-
Why hold a vote? If some people want to do it and others don't, then some people will do it while others won't.
Anyone is of course free to start their own project on their own servers, but a Wikimedia brand project should have support from a substantial number of, er, Wikimedians. We're not a wiki hosting provider.
Regards,
Erik
Erik Moeller wrote:
Toby wrote:
Why hold a vote? If some people want to do it and others don't, then some people will do it while others won't.
Anyone is of course free to start their own project on their own servers, but a Wikimedia brand project should have support from a substantial number of, er, Wikimedians. We're not a wiki hosting provider.
Since when does Wikimedia take votes to make these decisions? A substantial number of Wikimedians /does/ want to do Wikibooks. I don't need any vote to prove this.
-- Toby
Toby-
Anyone is of course free to start their own project on their own servers, but a Wikimedia brand project should have support from a substantial number of, er, Wikimedians. We're not a wiki hosting provider.
Since when does Wikimedia take votes to make these decisions?
We never did. I proposed that we should start.
A substantial number of Wikimedians /does/ want to do Wikibooks.
Certainly.
I don't need any vote to prove this.
A vote would help to determine if there are many Wikimedians who are against the project. I would have voted against the Wikibook project in its present "Textbook" form, for example. There are many projects where there will be dissent among Wikimedians on whether they should be operated by Wikimedia or not. Take POV projects like Disinfopedia, for example -- I'm sure there are many Wikimedians who like the idea and would love it to run under the Wikimedia banner. But many others would be against this, either because they see NPOV violated, or because they see *their* POV violated.
In that case, it would not be enough to simply say "Look, it's quite obvious that many people want this, so quit yer whining already." A formalized voting process after the project plan has been finalized helps to address such concerns, and makes sure that a large number of Wikimedians is exposed to every new idea -- if not in the planning phase, then in the voting phase -- and gets a fair chance to voice their dissent.
The alternative would be to let Jimbo decide in each individual case.
Regards,
Erik
On Sat, Jul 26, 2003 at 05:40:00AM +0200, Erik Moeller wrote:
Toby-
Anyone is of course free to start their own project on their own servers, but a Wikimedia brand project should have support from a substantial number of, er, Wikimedians. We're not a wiki hosting provider.
Since when does Wikimedia take votes to make these decisions?
We never did. I proposed that we should start.
There is no consensus to switch from using consensus to using voting.
Tomasz-
On Sat, Jul 26, 2003 at 05:40:00AM +0200, Erik Moeller wrote:
Toby-
Anyone is of course free to start their own project on their own servers, but a Wikimedia brand project should have support from a substantial number of, er, Wikimedians. We're not a wiki hosting provider.
Since when does Wikimedia take votes to make these decisions?
We never did. I proposed that we should start.
There is no consensus to switch from using consensus to using voting.
There doesn't need to be. Such policy decisions are made, and have been made, by Jimbo.
Regards,
Erik
On Sat, Jul 26, 2003 at 05:13:00PM +0200, Erik Moeller wrote:
There is no consensus to switch from using consensus to using voting.
There doesn't need to be. Such policy decisions are made, and have been made, by Jimbo.
Don't pretend you don't know how world works. Nobody has any "magical" powers over the project. It's open projects and if things will be done against will of contributors, people will just move away. Last time we had this problem with advertising, it ended with Enciclopedia Libre fork.
Tomasz-
On Sat, Jul 26, 2003 at 05:13:00PM +0200, Erik Moeller wrote:
There is no consensus to switch from using consensus to using voting.
There doesn't need to be. Such policy decisions are made, and have been made, by Jimbo.
Don't pretend you don't know how world works. Nobody has any "magical" powers over the project. It's open projects and if things will be done against will of contributors, people will just move away. Last time we had this problem with advertising, it ended with Enciclopedia Libre fork.
First, it is unlikely that a decision to use voting before starting a new project would inspire a movement of contributors against it, given that such contributors would be a small minority and scattered across all Wikipedias (notably, the decision by Jimbo to authorize a vote on the article count methodology did not have any such repercussions, nor will the vote on the new logo).
Second, any fork at this point is unlikely to succeed. The Enciclopedia Libre fork happened in the early stages of the Spanish Wikipedia (and great good did it do them -- they're using outdated software, and the Spanish Wikipedia just keeps on growing; they just reached 5000 articles). The larger the project is, the more difficult will it be to keep two forks in sync, and this alone discourages forking to a substantial degree. Of course, Jimbo would probably not make a decision of which he knows that it would alienate a significant number of users. But the type of decision we are talking about does clearly not fall into this category.
Regards,
Erik
Erik Moeller wrote:
Toby Bartels wrote:
Erik Moeller wrote:
Anyone is of course free to start their own project on their own servers, but a Wikimedia brand project should have support from a substantial number of, er, Wikimedians. We're not a wiki hosting provider.
Since when does Wikimedia take votes to make these decisions?
We never did. I proposed that we should start.
And we'll see how much support your proposal gets. ^_^
A substantial number of Wikimedians /does/ want to do Wikibooks.
Certainly.
Yet you imply above that we can't know this without having a vote. I agree with you that a project must have the support of a substantial number. How much is substantial? you ask. Enough to get it happening, I reply. This is not determined by votes, it's determined by action. There's no reason why a project must have the support of a majority. For example, I've never been particularly fond of Wiktionary, but that's all right -- I just don't use it myself.
I don't need any vote to prove this.
A vote would help to determine if there are many Wikimedians who are against the project. I would have voted against the Wikibook project in its present "Textbook" form, for example. There are many projects where there will be dissent among Wikimedians on whether they should be operated by Wikimedia or not. Take POV projects like Disinfopedia, for example -- I'm sure there are many Wikimedians who like the idea and would love it to run under the Wikimedia banner. But many others would be against this, either because they see NPOV violated, or because they see *their* POV violated.
NPOV is a special case. A project that violated NPOV would draw Jimbo's ire, and the Wikimedia Board of Directors would stop it (assuming that Jimbo retains /any/ significant influence there). But I'll assume that you can come up with an example that doesn't fall into this special case.
In that case, it would not be enough to simply say "Look, it's quite obvious that many people want this, so quit yer whining already." A formalized voting process after the project plan has been finalized helps to address such concerns, and makes sure that a large number of Wikimedians is exposed to every new idea -- if not in the planning phase, then in the voting phase -- and gets a fair chance to voice their dissent.
In the case of the Wikibooks project, I don't know what a vote would do to draw people's attention more than what has already happened. You are commenting! and your concerns about excluding cookbooks are even being addressed. (I'll even support you on a change of URL.) The process has been perfectly out in the open.
The alternative would be to let Jimbo decide in each individual case.
Another alternative is to allow any project with enough interest that a developer will write the necessary code and people work on it. Then modify that by allowing Jimbo (or rather, the Wikimedia Board) to stop projects that violate NPOV (and a few other rules, like educational purpose, that we can decide on by consensus).
Potentially, there's an issue of the finiteness of Wikimedia's resources. Perhaps we get so many projects that we bog down the servers! OT1H, Wikibooks isn't creating more users now, hence no more load. But OTOH, potentially Wikibooks, Wiktionary, and Wikipedia together could manage to /draw/ more users, hence more load, than only two would. So, we may have to start making decisions about resource management. But there's no need to institute procedures now for problems that may never arise -- [[Wiki:YagNi]]. (Mind you, that doesn't mean that /you/ can't start planning for it!)
-- Toby
Toby-
look, I can agree on this: Only hold a vote if there is an actual substantial number of dissenters, and if there isn't, just move on with the project. New project plans would have to be announced in the proper places so that every dissenter gets an opportunity to object. Silently ignoring dissenters, starting projects without giving people a proper opportunity to voice their objections or letting them bog down the whole process even though they are just a small minority is all not desirable. Consensus can not always be reached, and in these cases, we use voting.
Regards,
Erik
Erik Moeller wrote:
look, I can agree on this: Only hold a vote if there is an actual substantial number of dissenters, and if there isn't, just move on with the project.
Then we don't need a vote in this case then, do we?
New project plans would have to be announced in the proper places so that every dissenter gets an opportunity to object.
We need an announcements list for this sort of thing. Or a Wikimedia list that discusses only Foundation-wide policy, not focussed on the encyclopaedia.
Silently ignoring dissenters, starting projects without giving people a proper opportunity to voice their objections or letting them bog down the whole process even though they are just a small minority is all not desirable.
Yes, this is true. I'm not sure why you mention it. Certainly there was never any risk of this happening in this case. The idea of putting the vote at the /end/ of the policy-making process is what really throws me -- dissent should be voiced by then.
Consensus can not always be reached, and in these cases, we use voting.
Maybe, but that's not even really relevant. So what if there's no consensus that we need a textbook project? Or so what if it doesn't even get a majority? Objection should only be for broad principles, like NPOV, which should be decided by the Wikimedia Foundation in general. (Quite possibly, the Board may decide them despite your and my opinion!)
-- Toby
Daniel Mayer:
......
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.
I prefer a more organic approach in which the rules are made based on
actual
experience on what does and does not work. Yeah, of course, some basic parameters should be decided before that but those should be minima.
----------- Good advice.
Regarding any textbook project that hopes to impact K-12, the only thing necessary to have is the general framework in pace as a guideline, and possibly a few working examples (existing textbooks) in hand to get a feel for the 'demeanor' of the kind of material that is used 'on the ground' - it's a good starting point.
textbook-l@lists.wikimedia.org