Forking and joining should suggest standards

Hi Dysprosia! I welcome this initiative to present a more coherent Wikibooks for editors and readers. Clearly, community effort should be bundeled to well-defined projects, and in this sense a good forking policy is necessary.

Let's name things: I guess you are mostly concerned about the Programming:C plus plus <-> Programming: C -/- -/- fork. Suppose both parties agree to join the efforts again - whose style should be adopted? Who should be the winner, who the loser? I guess, the debate would continue, if it were not for standards.

Another hot point for forks is the effort of Wikiversity vs. Wikibooks. I don't know how active the former group still is, but content might be duplicated there and here, reducing the quality effort that could in principle be put into one joint effort Wikibook.

Also, with a lot of "New Wikibooks" recently, there is a high chance that content is created twice.

What I wanted to suggest for a long time is, to set up such a standard committee for Wikibooks. We have all the ingredients, we could watch Wikibooks grow for a long time, certainly, browsing around, we see which concepts work and which don't - which books are easy to navigate around and which are not. Since we now have subpages enabled, I would suggest to form a standard committee for Wikibooks, that first works for a couple of weeks to agree on a set of simple and easily adoptable standards, that would work best on Wikibooks. (As with every standard, it is a suggestion that people might adopt to but don't have to). Standards might include:

1. Using a uniform naming convention for new books or when joining books: A new standard might be (but of course it can be discussed)

Bookname                    -> use this for the main page, including contents
Bookname/Cover              -> use this for cover
Bookname/Authors            -> use this for authors
Bookname/Introduction       -> introduction
Bookname/Chapterdescription -> use this for chapters

e.g. Organic chemistry/Foundational concepts

1. The standard would recommend the newly introduced subpages.
2. The standard would suggest a capitalization of names (e.g. all small except first letter or abbreviations)
3. The standard would suggest to name the main page of the book as the bookname. (not like e.g. Teaching Assistant in France Survival Guide as main page and Assistant in France:Application as chapter pages. Also the main page should be renamed to Assistant in France)
4. The standard should discourage the use of numbers for chapter names (e.g. "Book/Chapter 1", "Book/Chapter 2" ...), as it is done in Geometry. This is because it would be very hard to insert a new chapter between existing chapters. When explicit names are used this poses no problem.
5. These standards make the future update of SQL queries on books easier.
6. Also, it might be a new standard, NOT to include the bookshelf name in the title. E.g. "Programming:C plus plus" should in future just be "C plus plus". This is to make Wikibooks more coherent (there is also no "Languages:German" or "Science:Mathematics" but the book's name is plainly "German" or "Mathematics".) Books can be sorted on bookshelves, but the book title itself should not reflect this. (to be discussed).

2. Splitting a book into reasonable chapters, and not having everything on one side.

1. Smaller pages are better for online-viewing of books.
2. On the other hand, there is no point in dividing a page into chapters that each only fill a few lines.
3. Having only 1 layer of chapters seems ideal for most books. Very large books (like Organic chemistry) will need 2 layers, but the suggestion should be to introduce the second layer only when necessary - not before. (like Business English that has 2 levels of chapters where most will be empty for a long time.. my personal guess. 1 level of chapters would be more than enough to let people work on the book in a coordinated way.)

3. Provide a print version. Using templates, a book could provide a print version where all chapters of a book are displayed on one page for printing. A book that does this is e.g. Computer Science:Data Structures. By providing a set of generally available templates, this could be made much easier. -> Hence a good standard committee.

Having this print version will take away one of the reasons for the unlucky C -/- -/- fork.

4. Books that follow the standard should have the right to carry a special logo "Wikibook standard 05" (like Fortran 95 and the like..). Someone should create a nice logo, like the CSS or XHTML logos from W3C.

5. Of course, there is no point in transforming very large books like Cookbook or Organic chemistry immediately, but there should be the possibility of an easy transition (e.g. that the standard is introduced chapter by chapter). ("Wikibook standard 05 Transitional"?!?)

The standard committee might even set up a Wikibook, called the "Standard Wikibook" (after having resolved the discussion points above), to present one Wikibook that explains all the rules of the standard, at the same time setting an excellent example for a good Wikibook. The standard committee might then continue to transform excellent books to adopt to the Wikibook Standard 05.

Having agreed on a standard first, joining of forks would be a very natural procedure.

What do you think about this? Dysprosia, would you be interested in being part of the committee? Who else might be a good candidate for the committee? Who is interested in joining? --Andreas 10:43, 15 Feb 2005 (UTC)

I've had the idea to start the Wikibooks:Manual of Style akin to Wikipedia's, but can be more prescriptive. Some of the points raised will be catered by the MoS. The print version however is generated automatically in Monobook using stylesheets, so if you print a Wikibooks page, it will come out pretty already. However, a project to ensure MoS conformity is a great idea. Dysprosia 04:29, 2 Mar 2005 (UTC)

Hi Dysprosia. The "Print version" I had in mind goes beyond the Monobook print style: The idea is, to have all modules of a book on 1 page, so if you print it, you will get the whole book. Yet, for online viewing the book is organized in several modules. This works in principle by having one page called "...(print version)" that includes as templates {{...}} all other pages of the book.

I like your "manual of style". It is a very good start. If I have time, and you don't oppose, I'll contribute by converting it into an example Wikibook (with cover, Authors, printversion, subpages, navigation...). I think, an example Wikibook would be more effective and easier to understand, than just writing about how it should look like. Cheers, --Andreas 08:59, 2 Mar 2005 (UTC)

I did think of making it a Wikibook, but thought against it. I don't think the amount of material will be sufficient to make it into a Wikibook proper. Several things though I think will need to be voted on - the hierachy method being one of them. Dysprosia 11:01, 2 Mar 2005 (UTC)

We now have a Wikibooks:Naming policy. --DavidCary (talk) 20:56, 1 February 2008 (UTC)

Support of this policy

I support this policy as it is in its entirety. Please let it be so... KelvSYC 02:43, 17 Apr 2005 (UTC)

Programming:C plus plus and its fork Programming: C -/- -/-

(moved from Wikibooks:Staff lounge)

Things have taken an ugly turn in Programming:C plus plus with User:Panic2k4 deciding to fork off another page at Programming: C -/- -/-. See my failed attempt at getting the opinions of other wikibookians (apart from Panic and me) above at #Attracting contributors to a textbook: Differences from the 'pedia, and past discussions at Talk:Programming:C plus plus/single page and those discussions rearranged in Panic's new format at Talk:Programming: C -/- -/-.

I've replaced Programming:C plus plus with text asking people to contribute to Programming: C -/- -/- instead. Already the only reason I was in the debate was I feared there'd be two separate books on C++, viz. one at Programming:C plus plus and one in the many modules named [[Programming:C plus plus <chapter/section name>]] (See Programming:C plus plus Hello world for example). Now with the fork there is a possibility of getting 3 separate books. Doing these things would make it difficult to consolidate all the info. about C++, which places readers of such material at a disadvantage.

If this were wikipedia, we could've added a vote on single- vs. multiple- pages for books, but here the traffic is so low, almost no one would vote. In fact no one might read this thread, just like no one read my previous thread above. -- Paddu 09:15, 18 Nov 2004 (UTC)

Hi,

I don't any know C++, so I can't help on the topic, but my opinion is:

• Programming: C -/- -/- is not a good name for an article title. It's ugly to type and probably bad to get it working in search engiges. I think, the simpler the title, the better. Maybe try C pp or something like this instead, if C++ is not possible. Actually I don't read C -/- -/- as C++, but as C minus-slash-minus minus-slash-minus. Even C -l- -l- or C -i- -i- or [[C -|- -|-]] would be better.
• The best length for a page is about 30 KB. So if an article is getting really bigger than that (say 40 KB), better to split in 2.

Just my 2 cts. Yann 16:45, 18 Nov 2004 (UTC)

My specific questions for now are:

1. whether to allow forks, and
2. whether to allow an old version of a talk page to be replicated elsewhere, misleading people into believing that's the original talk page, and making them miss the comments added to the original talk page after the talk-page "fork".

If the answer to the first is "no", not only must Programming: C -/- -/- be brought back to Programming:C plus plus, but the portion of Programming:C plus plus which is also in Programming:C plus plus Hello world, Programming:C plus plus Reference Tables, etc. must be removed from one of the places they appear in and replaced by a link to the other.

If the answer to the second is "no", the talk pages must also be merged in case the answer to the first is also "no". If the answer to the first is "yes", both the talk pages must be updated to reflect the latest state of comments.

I would say NO to both, but I am quite new in Wikibooks, although I edit Wikipedia for 2 years. And the option everything in one VERY BIG page is not reasonable. Yann 20:23, 18 Nov 2004 (UTC)

A1. I'm not sure on the meaning of fork, if you mean a duplicate of an existing page, then no. If you mean to have chapter pages, then yes. A naming convention can be "Programming:C plus plus:Program:Hello World", ""Programming:C plus plus:Program:Simple Calculator", etc

A2. Talk pages should not be replicated elsewhere. -- [[User:Mkn|Mkn (Talk)]] 13:35, 23 Nov 2004 (UTC)

With lower priority, I'd like to know:

1. if a thread in a talk page can be called "dead" and archived, if something was added to it just a month back, and
2. whether first level headers are to be used in titling sections (they are too large, and befit only the title of the page).

Note that I'm not that bothered about getting an answer to the multiple- vs. single-module immediately (I should've mentioned this above). But while that is being decided, the above problems must be resolved (esp. since these concern the talk pages on which that discussion can be held). -- Paddu 17:55, 18 Nov 2004 (UTC)

Forgot to add this one in the lower priority section:

3. if threads with the last comment made a month ago can be regarded as "dead proposals" and archived, given the traffic that comes to Wikibooks.

-- Paddu 18:56, 22 Nov 2004 (UTC)

A1. If a thread has been resolved, then make a summary sentence to acknowledge it and delete the thread. Otherwise, archive it if the talk page gets too long.

A2. I think second level headers should be used for titling sections.

A3. I don't see any problem with archiving older messages. Try to resolve as many of the threads as possible. I'm not sure about other people, but I wouldn't want to read so many messages. -- [[User:Mkn|Mkn (Talk)]] 13:35, 23 Nov 2004 (UTC)

OK, since someone other than Panic2k4 says that a month old message can be archived, I've removed my (pet peeve) Talk:Programming:C plus plus#Common programming errors & moved that to Talk:Programming:C plus plus Hello world (Hello world is where I started thinking about highlighting common programming errors in boxes). Just archiving and forgetting might be OK, but having another section in the talk that says that his proposal is "dead" doesn't seem OK, since someone can start implementing this proposal any time. Note that there was no opposition to the proposal. Just that I didn't find the time to implement it within a month (& a few more days now). -- Paddu 17:31, 23 Nov 2004 (UTC)

I am opposed to this policy

There are many subjects that benefit from the introduction of slightly different viewpoints. I have about 8 textbooks on Special Relativity, most of which cover similar ground but they are all useful. There is also the problem of national curricula - the British A-Level science curriculum might be different from US SATS requirements. It might be useful as a guideline but should certainly not be enforced. It might also be reasonable if a fork contains more than, say, 30% of the content of the book from which it has been forked. RobinH 10:45, 17 May 2006 (UTC)

The policy is designed to prevent each new wikibookian from writing their own personal version of already existing books. We don't need multiple cookbooks, C++ books, etc. (exceptions as listed apply) Books designed for a specific national curriculum are acceptable since they are geared towards different audiences. The policy was initially created because there was an already existing C++ book which was forked over formatting issues; that should have been resolved internally instead of resulting in forking. Advanced topics such as special relativity are probably more difficult to merge and centralize, but all efforts should be made to do so. We are, after all, writing textbooks not theoretical essays. Kellen ^T 11:35, 23 May 2006 (UTC)

The dispute about the C++ book was not only on format, content was the major problem...--Panic 13:54, 23 May 2006 (UTC)

Many subjects can be studied in varying degrees of depth, so would it not make sense to have 'Elementary' and 'Advanced' books for some subjects. Of course the elementary book would be a prerequisite for the advanced one, so that information does not need to be unnecessarily repeated. --Waqjan (talk) 22:15, 11 December 2007 (UTC)

The proposal is in need of update, see for instance the C++ page, even the forced merge of the previous Programming:C++ was see as erroneous, but is now a faith accompli readdressing it would be of no service, in the mean time several parallel works do now exist in several subjects, this has both positive and negative points, the major one being the fragmentation of the contributors poll but this also increases the freedom of choice and a more freedom to implement divergent approaches, same of those you have just enumerated. --Panic (talk) 00:20, 12 December 2007 (UTC)

Vote

Support

• Ultimadesigns 01:20, 10 June 2006 (UTC)
• Je suis 01:08, 17 June 2006 (UTC)

Oppose

• --Panic 14:36, 11 June 2006 (UTC)

Move that Forking policy to be rejected and/or be turned it into a guideline

A forking policy without a previous understanding of a derived work and approval of a Wikibooks:General_voting_rules or a definition to a book community should not exist. Forking brings content, the problem with forking a work on wikibooks is not space as if equal parts are on different works those can be merged, it will only provide a different context to the content on both works.--Panic 01:09, 10 October 2006 (UTC)

Erm. Sorry, but I'm not quite understanding your rationale. Actually, I'm not understanding either what you mean by "guide". A guideline? --Swift 06:06, 10 October 2006 (UTC)

Yup, sorry. --Panic 06:55, 10 October 2006 (UTC)

Could you please reword your rationale? I don't quite understand it. Specifically the phrases "previous understanding of a derived work", "approval of a Wikibooks:General_voting_rules" and "definition to a book community". --Swift 08:38, 10 October 2006 (UTC)

A guideline allows for circumstances where its recommendations do not apply. Can you give examples where it would be benefitial to the project that the rules be bent? --Swift 08:38, 10 October 2006 (UTC)

• Oppose. This particular text needs some work, but I think we need some kind of policy against unnecessary forking of material. Furthermore, it has been de facto wikibooks policy for some time that multiple books on a single subject are merged. In general, it's better to make policy conform to the community then it is to try and change the community by instantiating new policy. --Whiteknight (talk) (projects) 03:54, 10 October 2006 (UTC)

  I think you are not opposing because we need a fork prevention policy, but because content shouldn't be duplicated, I agree with that and a merge should be enforced to the oldest copy of the offending page, but by providing multiple instances of the same content to be accessible in different ways even with different structures we are providing a service to readers and facilitating the work of contributors...

  More, every edit of a book on wikibooks creates a fork (derived work) of the original text/book, even more problematic is that by altering a secondary page you can't keep up with all versions (they still exist on wikibooks) of a work as there is no way a easy reversal or to display of a previous version by date, and a fork policy without a proper definition to the merge process is unworkable. --Panic 04:27, 10 October 2006 (UTC)

  Since you have not extended your view on the opposition, I will try to explain my points a bit more, we (Wikibooks community) should have a Merge policy and a Fork guideline (the Merge policy would enable correcting abuses and validate the guideline) the first would "force" a merge of any abandoned work or give some force to impose limitations to forks, the guideline would define a fork and explain how and why to avoid one and how to proceed with one within certain parameters or pointing to the Merge policy, the bottom line is that by avoiding forks we are not giving the proper treatment to Wikibooks objectives, we need authors, forks enable authors to create by forking a work, this would effectively reduce any chance for conflicts and solve many other problems and enable and even foster competition on the forked versions, let imagine for example we place a time limit on the fork and original version and would force a merge with the book with more content/votes or near to "completion" or some similar resolution in a fixed time frame or even passing a similar process like VfD on both copies (I think the whole community should have a say in selecting the version to keep on Wikibooks).

  On the other side with a no fork rule the only result will be less authors (or if you prefer less content) because increased protectionism for the existing versions, reducing authors freedom and empowering users that probably would not have the same level of commitment to block or entangle productive users from contributing and will in fact be increasing the chance for conflicts. --Panic 05:59, 16 January 2007 (UTC)

Proposal

See Wikibooks:Forking proposal for some technical fixes that could help make this policy more effective. --SB_Johnny | ^talk 13:33, 15 January 2007 (UTC)

The Wikibooks:Forking proposal was later moved to Wikibooks:Forking and Merging before being merged into this proposal; the Wikibooks:Forking policy. --Swift (talk) 13:08, 16 February 2009 (UTC)

Wikibooks:Forking proposal

The following section has been merged in from Wikibooks talk:Forking and Merging. --Swift (talk) 13:08, 16 February 2009 (UTC)

This sounds like a workaround rather than a "solution" to the problem of wanting to properly copy the materials to a new page. But if it's the only way to do it, I don't have any problems with it myself. Kellen ^T 16:07, 15 January 2007 (UTC)

Yep, it is. There's currently no way to duplicate a page without transwikiing. I think it has a certain charm to it though, since it will keep us tied to our younger sister-project in a positive way. --SB_Johnny | ^talk 16:44, 15 January 2007 (UTC)

I have no real objection to forking, if someone were to fork a book I was working on I would just take cuttings from their new work where needed and put them back in the original book! Your idea for forking in a more structured way sounds interesting but will probably need an admin to do it. The only big problem with forking is that it must not be used to solve an edit dispute - I would rather have two parallel texts in the one book than a fork for this purpose. RobinH 18:04, 15 January 2007 (UTC)

This is a technical proposal on how to properly fork a page in accordance with WB:FORK, not a proposal to allow general purpose forking. Kellen ^T 19:02, 15 January 2007 (UTC)

I support and would like to use it as soon as it's ready to be implemented. --xixtas 02:41, 13 February 2007 (UTC)

I'm still not convinced of a need for forking material at all. The project has gotten along fine by shunning forks in the past. I can't think of a situation where material needs to be shared between books, and transclusion can't do the same job. Wikibooks has too few users writing on any one topic for us to be forking content all over the place. We just dont have the infrastructure to support it. --Whiteknight (talk) (projects) 02:53, 13 February 2007 (UTC)

This feature would allow contributors greater freedom to create books, by allowing them to build upon the contributions of others in alternative directions. The best way to get more people to contribute (and continue to do so) is to make whatever tools they might need available to them. While we have had reasons to shun certain kinds of forks before, the kind of forking being discussed here isn't about resolving conflicts between editors, but rather conflicts between topics. Even the garden book might require forking at some point, if separate textbooks were needed for tropical or monsoon-climate gardening, or large-scale agriculture in any number of climates (those books would address a lot of the same things, but from different technical perspectives). Similarly, if someone were to write a textbook on hydrology, much of that information could be used as a basis for a book on petroleum exploration... but would you insist that those two books share the same chapters, rather than forking them off? --SB_Johnny | ^talk 13:58, 13 February 2007 (UTC)

In the first case, with the gardening book, it would seem to me more appropriate to simply expand the current book to fit additional technical perspectives. For instance, every page could have a section for "temperate climates" and a section for "monsoon climates", etc. In this way, people wouldn't need to figure out which climate they were in before they started reading a book, the book would contain all the information for everybody who needs it.

In the second case, it would be much easier for the petroleum exploration book to say "This book relies heavily on principals already discussed in [[hydrology]], and the reader is expected to have read that book first". This way, we dont need to duplicate content at all, and we are advertising our books internally. --Whiteknight (talk) (projects) 14:15, 13 February 2007 (UTC)

This really seems like an argument for putting square pegs into round holes. For example, having a separate section on each page for various climates would make the pages much larger than they would need to be, and would be similar to including versions in 4 different languages in order to avoid having to make duplicate books, or perhaps similar to insisting that a book on agriculture be required to be part of a biology book. As another example, a book on the History of the American Revolution would perhaps need to mention what was going on in Britain and Europe at the time, but forcing authors to transclude chapters from European or British history books (if we're allowing those to be separate books, of course) would limit the teaching value... a book on British history isn't going to relate the events there to events in the colonies with the same clarity and vigor that would be desirable for the American Revolution book. What this feature would allow authors to do is just take chapters from that other book and condense/expand/transform the material to fit the subject. --SB_Johnny | ^talk 15:03, 13 February 2007 (UTC)

If two pages contain the same information, they should be the same page. If two pages do not contain the same information, they should be separate pages. I can understand the idea of wanting to base the text of a new book off that of an existing book, but I can't see why we would want wholesale copying of pages and page histories to a new location. Sections of text that are being used verbatim between two or more modules should likely be templates or other transcluded pages. I've written several books that make use of the same tables or charts, and I transclude those tables individually where they are needed. Text that is not being used verbatim isn't likely to be generated by a copy operation anyway. --Whiteknight (talk) (projects) 15:15, 13 February 2007 (UTC)

(reset tabs←) That kind of transcluding might work for some books, but I assure you it won't for many other fields, both technical and non-technical. These kinds of forks might want to take a whole page from one book and transform it to fit the style and focus of another book. For an example, compare w:Aster (flower) and A Wikimanual of Gardening/Aster... the latter was built upon the former (using import), but takes an approach so different that even if transclusion of a Wikipedia article were possible, it would not be appropriate (and neither would transcluding that chapter be valid for Wikipedia).

We're not talking about images and tables. Most books don't use tables in the same way that engineering books do.

I really just don't understand why you want to force contributors to do workaround solutions... it's not necessary, it can seriously hamper the progress of writing a book, and quite frankly it imposes an artificial restriction that can be poisonous to the feeling of creative freedom a textbook-writer deserves to have. Again (using the example I understand the best), forcing a biology book, a botany book, a horticulture book, an agriculture book, a dichotomous key, and a local field guide to trees to all share the same chapters if the content addresses the same thing is rediculous, and I can assure you that the authors of those books won't do it. This feature is simply to allow a valid way to copy a chapter from one book in order to modify it for use in another book. It's a time and effort saving tool that contributors can use to make use of materials that are already available, rather than having to reinvent the wheel every time.

These are our alternatives:

1. Forbid the authors of any given book from using materials from any other book (maybe block them if they do?)
2. Ban the existence of 2 pages on wikibooks that address the same or very similar subjects (we can of course have a policy and jury board to decide when things are too similar to be permitted...).
3. Permit authors of one book to take materials from another book, and adapt it to fit the book they're working on (if this were required to be done using the import tools, there would at least be a "community filter" provided by the administrator who's making the copy).

--SB_Johnny | ^talk 15:58, 13 February 2007 (UTC)

I'm not really going to argue the point any further, If you say it's necessary I will follow your judgement on the matter. There are a couple of things that I dont want to see resulting from this:

• People duplicating existing books, and abandoning them (especially new or short-term users).
• People forking books because of disputes over content.
• Duplicate books not being sufficiently different, and requiring later effort to merge them back together.

Even if we have a forking policy, that doesnt mean that we no longer merge related books together. I think it might be prudent, before we allow forks to be created in this manner, that authors should have to specify exactly what their plans are with the duplicate material, so we can try to avoid the problems i've listed. --Whiteknight (talk) (projects) 17:41, 13 February 2007 (UTC)

I share those concerns... I think te first and third are pretty much the same issue on this concern (the only way two books would end up being insufficiently distinct would be if one or the other was abandoned).

Since it's clear there will be vocal opposition to getting the tools set up without creating a policy first, I'm going to move this page to become an unstable branch of the current forking policy so that debate can continue there. The tools I had in mind just make it easier (or at least more graceful) than the alternatives, but the alternative methods aren't so arduous that we couldn't make do until the policy has some trial runs and we can see how well the actual forking part works for us. --SB_Johnny | ^talk 22:45, 13 February 2007 (UTC)

Switched it around a bit (page name changed now)

The following section has been merged in from Wikibooks talk:Forking and Merging. --Swift (talk) 13:08, 16 February 2009 (UTC)

It seemed sensible to try to do this here, since we've been discussing it here. The template (which needs writing) for the talk page should do the same thing the tool would have done, and should include a category so that we can fix any forks in the future (I don't think there will be many, so catch-up should be a small chore).

I'll work more on it in the morning, but it should have some language to address the concern of making forks without discussing it first, in the hopes of preventing abuse and/or abortive forks. --SB_Johnny | ^talk 02:46, 14 February 2007 (UTC)

Renewed proposal

I've merged and trimmed what I see as the essence of Wikibooks:Forking and Merging, Wikibooks:Subject policy and this page. I don't think there is any lack of consensus with the general idea of this proposal and if we keep it short and simple without going into hypothetical details, we should be able to make this official without difficulty.

Should the need for more nuance present itself, we can deal with it then and reflect what we've learnt in this policy.

For now, I suggest that we delete the other two, merge in their edit histories and make this official. --Swift (talk) 11:47, 3 February 2009 (UTC)

This is premature, and requires formalization of announcement and proceedings (skipping any of those will remove any validity to the discussion).

The merges should be agreed and worked upon before a real discussion on the subject takes place (as a way of adopting the text as a guideline or policy), since only then similar view points on the issue can consistently be argued and converged upon without people requesting the adoption of special versions of the text.

There is also the problem of understating definitions (I've just added one for the fork, to this text), some of the other versions get into that more verbosely, I prefer reducing them to the minimum or even using links to Wikipedia or Wiktionary would probably do a better job, but that lead into another problem...

How we can define a Fork on a book, fork is used most commonly on the software world to characterize a split on the evolution of a software project (arguably derived from a fork of a process in an operating system), that is, when a person or group of people decide to take the last version of the project and build a derivative with a distinct scope or objective, there are also forks that started because splits in policy and lack of coordination between the participants, in any case it is hard to define and argue that any fork is negative or has a negative impact on the work itself or on the end user, it does undeniably have an impact on the community working on the project but if things reach the fork stage then it doesn't really count since agreement on the evolution of the project has already failed. This rational can easily be proven if taken in consideration situations were forks aren't possible due to licensing or other legal o structural consideration, so forking is mostly a positive thing in itself, it removes barriers and foster creativity and the undertaking of different approaches, but can we call fork to a book split, hardly.

If we agree in preventing this kind of book slits in project, we should define that "our" forks are only valid to projects namespaces, since we work on the bases of the GFDL all our work are forks or splits of a previous edit, even some of the project we have on Wikibooks are "forks" of works, derivatives, or revisions, each time there is a page edit there is a split from the previous revision. But this causes another issue on copy of content across books on Wikibooks, how quantitatively we define a split or a fork (or whatever name we get to call it), only on 100% identical replication of a work? What about transclusions they should be considered in this shouldn't they (even only to exclude them from what we consider replication).

Ultimately I don't see "forks" as a problem, I agree that they should be the last solution, but if we adopt a good merge policy forks will not be an issue nor shall we have a good enough reason to object to them, we should however clearly define what we call a fork on Wikibooks and state that only failing to reach a consensus regarding the evolution of project should be a reason for one with some other hard considerations (ie recent number of edits/contributions to the work etc), we shouldn't encourage forks only so people can make a point or prevent a work from evolving. As the first person to fork a book and the basis for the creation of the policy and the executor of the "forced" merge, I do have a good understanding on the needs and problems regarding both issues and the rationals that defend or contest such decisions. --Panic (talk) 21:37, 3 February 2009 (UTC)

"This is premature, and requires formalization of announcement and proceedings" No, we have no such policies.

"The merges should be agreed and worked upon before a real discussion on the subject takes place" As I explained above. These mergers are the common denominator of the three merged. What remains are details that we can be without for now. They can be added later.

"There is also the problem of understating definitions" This is not a problem. The proposal is clear in what the criteria for creating a seperate book is.

Many of your edits to the policy were helpful, Panic, but I re-added "is not an acceptable alternative to improving existing content or resolving disputes." which you had removed with the summary: "removed reason since all should be invalid added must since this part should be enforced". Provisions like this do not limit the scope, but help hone its aim. --Swift (talk) 03:12, 4 February 2009 (UTC)

On the premature nature of the renewal of the proposal, the thing is that a discussion should take place to bring all proponents to the table (since there are several texts on the subject. None approved.

The previous text on this proposal was enforced in the past, badly since it was not a result of a community decission process), in any case, the remark about the need for announcement and proceedings is still pertinent.

If you really intend on lunching the process to make the text into a approved policy or guideline you have to announce it (normal place is on general announcements forum), and establish the proceeding requirements and set a time frame to the outcome, previous decisions took, what I see as productive and conclusive format, this has somehow not been fallowed on the bots proposal, resulting in its status to become inconclusive and even if the participants now came to a consensus its validity would be object of debate. Even a non approval status to the previous discussion would be more clean.

On the merges proposals I still think that they should be resolved and acted upon before initiating an approval proceedings of this text, since it will remove and address other Wikibookians disagreements with it (they can be even considered a forks of this proposal :), since it predates any other text on the issue and the objective/function are similar) bringing everything to the table before is better than latter if you aim to bring consensus to the issue.

Regarding the definitions, I personally have no objection on that regard but from past discussions I know some other Wikibookians will (just examine the last few talk pages on similar decission processes, even the bot proposal IIRC was objected to on those grounds), I too dislike verbosity on policy and guideline text but recognize that establishing and nailing down some core definitions or interpretations is needed or the text will just be open to very distinct interpretations. (I above gave the problem of quantifying a "fork" or how forks aren't easily translated to a Wiki environment, even more under the GFDL, I do think you and me are talking on the same issue, but also took this chance to show that even a proposal text have and will probably be forked).

On the text changes I have no major objection just would like you to describe how forks are harmful to the Wikibooks project, and if is you intention to block future forks in general I also don't see a need to define one or two reasons that can promote one (the end of the same paragraph).

I see "forks" as unproductive at worst, but also see several benefits as described above. I again state that a strong merge guideline would address those problem in a non prohibitive and confrontational way. I'm not strongly against a fork policy (see previous thread on this page) but don't see it as incentive to productive participation to generate content. Can you state any problem with a fork that a later merge couldn't address?

A merge guideline, well constructed, would be inclusive rather than exclusive, and open to corrections, with the added benefit that volunteers would already contributed content to the project. --Panic (talk) 03:51, 4 February 2009 (UTC)

Wow, Panic. I can't remember if this is a record for you, but a 175 word paragraph without a full-stop is certainly impressive!

I had no intention of marking this official without bringing it to the attention of the community. Please don't make assumptions about people's motives or intentions.

"Can you state any problem with a fork that a later merge couldn't address?" This is mentioned in the policy:

"Books with similar content, scope and audience should be developed as a single wikibook in order to reduce the duplication of efforts."

Real-life examples abound. I can point to the Japanese book that I'm involved in (browse around the introduction pages, Talk:Japanese and its archives) which we've been stitching together from layers of contributions. We've already deleted over a hundred pages of duplicate content that we've merged. Another example is Foundations of Education and Instructional Assessment which is now in it's fourth edition, each of which has duplicate pages. From a reader's perspective, that's hardly a quality book. --Swift (talk) 06:47, 4 February 2009 (UTC)

There I fixed it for you (I did use commas) :) ...

I was going to ignore it but since you seem somewhat offended I must make it clear. I didn't make any assumptions about your actions here, I only called your attention to the facts as I see them, as can clearly be read above, and based on your own reply:

"This is premature, and requires formalization of announcement and proceedings" No, we have no such policies.

I could have misread you on your words, but clearly haven't. I recognize you are aware of Wikibooks:Decision making policy, this reply only made me lengthily restate the obvious. I was not claiming any wrong doing nor demanding you acted on it, only stating that this is the needed procedure, as for motives and intentions I strive to not state my assumptions as facts to others, something that I agree is rarely seen on this project, but be assured that if I ever make that mistake it will own up to it. I do prefer to be direct and if possible factual when I start pointing other peoples mistakes and expect others to do the same. Just take the above example, you assumed my assumption and acted as someone that interpreted my words as an act with bad intention, not so, as the can clearly be read on the posts above.

Claiming duplication of efforts is not a rational argument. People forking a work will not be working together nor in the same direction (if so the fork would not occur) so no real duplication of content/work will occur after the fork. I could however agree that contributors would probably have to duplicate corrections to content predating the fork, but this in no big problem since most of those corrections are done by people reading the work, and after the fork some heavy restructuring is expected in both works. I doubt a non contributor would initiate a fork in any circumstance. If a fork occurs I can assure you that only the more active and fit work would survive in the end, you must always keep in mind that all contributors are volunteers and a fork is not taken lightly and only by people wanting to actively contribute.

From the time I'm on the project I only have observed, IIRC, two other people thinking as a fork as a solution and I don't think anyone did come to fork, one was the OOP book, the other I forgot. If I'm not in error the Japanese work is a result at least of merging together two "distinct" works (something that involved also moving/renaming of the namespaces, you can better than me clarify the history), in any case you are discarding the issues concerning factual errors that existed (and had to be corrected), the book history, the size of the works and level of contributors/activity this all are factors that have an impact on completing a merge, it seems that you are only pointing negative aspects and not recognizing any added value, were the works stalled ?

In the case of the C++ book, were I had the experience of forking and merging, there was no real content difficulties since the original book stalled after the fork, besides minor structural changes, but I see merging a fork as an easier task that merging together two distinct books on the same subject (and I have done that also).

As for the Foundations of Education and Instructional Assessment I had examined it some time ago and can't really understand the project. I avoid doing even maintenance tasks on its pages even welcoming editors to it (I know they should be a target for promoting participation) but I have looked into the edit habits of a few and can't make any specific conclusion other that most are editors on a task for that particular project. Are you also considering those "editions" as forks ? Do you expect retroactive implementation of the policy? (I think a different approach must be found for those distinct issues). --Panic (talk) 10:32, 4 February 2009 (UTC)

I've been racking my brains how or if to respond to this. As before, you cling on to your view of others' motives and misconstrue or dismiss any counter-arguments to it. I'm going to leave this and move on. If you think I'm trying to Shanghai this proposal past the community without review, please report it in the general reading room or request reprimands in the administrative assistance reading room. --Swift (talk) 10:28, 12 February 2009 (UTC)

As far as I can tell, there is no objection to the merger itself in the discussion above. I'd like to move this on, so unless there are any substantive objections to that step, let's merge the page histories and archive the respective discussions in the coming days. --Swift (talk) 10:45, 12 February 2009 (UTC)

Done I'll archive the discussions later. I haven't quite decided when to push for a formal discussion to make this an official guideline or proposal, essay, or rejected. There are currently several other discussions in the community (notably the FlaggedRevs discussion on revising the +editor automatic granting criteria) which (should) take priority over this. --Swift (talk) 13:45, 16 February 2009 (UTC)

* Courses

The Physics Course, Arithmetic Course, Trigonometry Course, and Geometry Course books that appear to be low-quality poorly translated versions of content at another language Wikibooks dumped by an anonymous editor that refuses to engage with the community, with the mathematics books coming after the RFD of another mathematics book by likely the same person under another IP, almost make me want to try to push this to policy. At least I can take solace in the fact that all books have now been classified with {{status}} so that readers will gravitate toward higher-quality, more complete books. – Adrignola discuss 18:02, 13 February 2011 (UTC)