User talk:Mathmensch/Archives/2018/June

Problem with Template:Example
Hi Mathmensch,

I spotted "" on a few pages and traced the problem back to Template:Example. I checked the first few pages listed at Special:WhatLinksHere/Template:Example and they all had the problem. It started with this edit you made a few months ago:

Adding the possibility for a title is a good idea, but your edit breaks the pages that were using the template before your edit. Can you fix the template? (Or fix the articles that use it, but there's a few hundred so fixing the template is easier.)

An easy fix might be to make the title be argument number 2, and document this on the template page sot that if anyone wants a title, they can do Great floors (discuss • contribs) 08:53, 3 June 2018 (UTC)

Subject:University level mathematics
Hi. The tree, in itself, looks neat, but we need to work out how to handle this so it lives happily with the project infrastructure.

Subject space is very regimented, and the whole category infrastructure of the project exploits the known regimented structure of the subject pages. Each ordinary subject page consists of a single template call to subject page, which is specially wired to handle the various ways that the subject pages are used by other pages to extract appropriate information.

(For perspective, here's broadly how that information extraction works. Take for example Subject:Mathematics history.  The template takes parameters specifying one or two parent subjects, in this case Subject:Mathematics and Subject:History; and when the page is transcluded from outside subject space, ordinarily it reports on its parentage.  Who does this parentage querying?  Well, associated with each subject page are two other categories: a subject category, here :, which contains books that explicitly name that subject to template subjects on the book main page; and an allbooks category, here /all books, which contains all books that name either that subject or any of its descendants.  Each allbooks category queries the parentage of its subject, to file itself in the allbooks categories of the parents; and crucially, subjects on each book main page uses parentage queries to find all the allbooks categories to file the book in. And each subject category page transcludes the subject page in a modified way (using a parameter) to replicate the extensive information display that's generated on the subject page by template subject page.)

In the case of the thing you're setting up, I was thinking we might be able to put the tree you have in mind in the "summary" field of subject page. That would have the virtue of simplicity, since it would just use the existing infrastructure without change. Alternatively, we might be able to devise a variant of the subject page template, either by passing different parameters to the template or by setting up a whole separate template, that would be more suited to what you're trying to do. --Pi zero (discuss • contribs) 16:01, 25 October 2017 (UTC)


 * Let me first thank you for importing the template. On the other hand, it would of course be desirable to have some sort of template which leaves more room for editors to arrange the wikibooks on the page. I believe that how one would go about these things depends on one thing: What shall be the function of the subject pages? Is it:
 * a) To provide the surfer with a good and understandable overview of the subject (in which case I would favour something optically similar to the current system), or
 * b) solely to provide wikibooks authors with an overview of what has been done and what hasn't.


 * Another thing which would enter these kinds of considerations is this: Mathematics itself consists of many subjects, which, as can be seen from the subject page that I designed, may be arranged in a tree structure. This tree does not indicate that these subjects are "sub-subjects", but rather it is a tree of dependency. Still, it would be possible to paint a "rougher" tree, where complex analysis, distribution theory, partial differential equations and so on are part of an "analysis" category, algebraic and analytic geometry are part of a "geometry" section, and finally there could be a "combinatorics" section for graph theory and certainly an "algebra" section for things like universal algebra, homological algebra and so on. These may be "sub-subjects".


 * That said, and also with a view towards the future where we have refined wikibooks treating one subject, one could think about a template that does this: We have, for instance, a subject page for "mathematical analysis". This will then be the "root-level" subject. On it, we have a tree relating the different analysis wikibooks and a root of the tree, which is a (possibly abstract) node in the given graph on the high-level page, which is then the current page (Subject:University level mathematics). The trees of the root-level subjects are then transcluded onto the high-level page. I suppose that this would be rather difficult to set up and take time, so that only someone who is a very swift coder and has considerable experience with wiki templates can implement it. I'm also not quite sure how to define "abstract nodes" and how to translate them into an image, this would then be a technicality.


 * Normally, I would be quite happy using subject page, but honestly, the yellow background inhibits readability in my view. If the background could be set to white, I would implement this solution right away; in the short term, it seems acceptable, even though I dislike the current template structure in several respects:


 * I think that every template should be properly named and then fulfil its purpose according to that name. In particular, Robox should be named box, and in my view, the selection of a "theme" should be replaced by a field where one may enter the colors of the background, font and title bar. If that were the case, one could easily get rid of the yellow background. This is my view how it should be done. Further, I believe that the template code complexity and structure (in particular regarding sub-templates) should be reduced to a minimum, to give someone who wants to change something a quick overview. In particular, I dislike the existence of "core"-subtemplates, which to me, who did not create them, seems like an arbitrary "outsourcing" of code away from a place where it would actually belong.--Mathmensch (discuss • contribs) 19:46, 27 October 2017 (UTC)


 * Also, I noticed that for instance in Category:Book:Distribution_Theory, there is an enumeration of the chapters of the wikibook, which doubles the wikibook main page itself, as I designed it to be a table of contents. Hence, it would be good if the two pages could be merged into one. --Mathmensch (discuss • contribs) 15:05, 28 October 2017 (UTC)


 * Some fairly deep infrastructure issues here.


 * Regarding subtemplates. I am a firm believer that wiki markup is central to enabling the mission of wikis &mdash; imo the Foundation has made a profound blunder by effectively deprecating wiki markup in favor of using specialized side-languages and "structured data" &mdash; and I've found that big hairy templates with all the different logical concerns muddled up on one page are effectively write-only code.  I'm very much in favor of separating logical concerns onto separate pages by means of subtemplating.  (A case in point is BookCat, whose ongoing evolution I have been involved with for years as it has undergone many upgrades; it eventually became imho an unreadable mess, but is now cleanly modularized into separate parts &mdash; with the side benefit that one can change its behavior in one namespace without forcing the wiki software to purge all the pages that use BookCat in another namespace, nice when it means not purging sixty thousand mainspace pages.)


 * The layout tactics of the subject pages predate me on the project. I introduced the key logic by which the subject pages interact with other pages, and I felt (and still feel) that if that logic weren't carefully isolated from the page layout (by means of subtemplating) the result would be an unmaintainable snarl.  I have no personal investment in gory details of the page layout... although I've never, historically, had any strong reason to want to change a layout that seemed serviceable and already messy enough to evoke the principle "if it ain't broke, don't fix it".


 * The purposes of these different kinds of pages should, perhaps, be understood in the context of how they came about.


 * The book categories were, afaik, standard practice from the earliest years of the project; the wiki software provides a special page for tracking uncategorized pages, so I suppose it makes sense that if a page has a proper place on the project &mdash; as part of a particular book &mdash; that ought to be reflected by filing it in a category of pages associated with the book. Some books make further use of the category, some don't; but imho, infrastructurally, the category is there to aid in keeping track of each page's role in the Wikibooks project as a whole, and other functions, like a table of contents, belong in mainspace.  Those other functions might usefully employ the book category.  There is a facility called dynamic page list for listing pages belonging to all of a set of (up to six) categories, which was developed for use on Wikinews and has turned out to be sometimes hugely useful on various other sister projects; I think it's even used on Wikipedia, thought I don't immediately recall for what; but imho if book categories are used that way the actual point-of-use should be in mainspace.  I don't think content should end up in category space.


 * We've had a longer, more winding road to subjects as they now exist. Originally (I believe; this is before my time on Wikibooks) there were pages called bookshelves.  The sort of thing you've been trying to set up seems quite compatible with the bookshelf concept, and in fact your approach might have fit right in.  However, the bookshelf concept ultimately failed.  Afaik, the failure of bookshelves is an instance of a much broader principle:  centralized infrastructure to help keep track of wiki content must incur maintenance costs proportional only to the amount of tracking infrastructure, independent of the amount of content tracked.  If any of the costs are proportional to the amount of content tracked, those costs must be entirely distributed to the content.  (I appreciate this as a general principle partly because I've seen other examples of the same principle, over on Wikinews.)  Over time &mdash;again, afaik&mdash; the bookshelves didn't get maintained, becoming increasingly useless which could only exacerbate their neglect.


 * An alternative arrangement was started, with its own namespace: a subject hierarchy, using DPLs so that, indeed, the responsibility for putting particular books into particular subjects was entirely distributed to the books themselves, in the form of a template call on the main page of each book to template subjects, naming the most-specific subject of the book, or occasionally two subjects, more rarely more than two. This almost worked, but for some years it had a tragic flaw, which had to be fixed if the community was going to commit to deprecating bookshelves in favor of subjects.  The flaw was that a book would only be listed by the DPL of the particular subjects that it listed through the subjects template on its main page.  For example, a book in subject "Constructed languages" wouldn't be listed by the DPL on subject "Languages".  Books shouldn't have to be edited to reflect which subjects are ancestors/descendants of which, just as subjects shouldn't have to be edited to reflect which books belong to them.  The solution (which I implemented) was to set up the extensive internal "all books" mechanism, which I outlined above, so that when a book lists a narrow subject like "Constructed languages", the subjects template also automatically adds the book to the hidden allbooks categories of all the ancestors of that subject &mdash; and each ancestor page has DPLs to list not only books that explicitly name that subject, but also all books that list any descendant of that subject.  There was community consensus that, once that was done, bookshelves could be officially deprecated in favor of subjects.  Technically, I was only able to make this work because Wikibooks already had all this uniform infrastructure already in place:  the subject pages all substantially identical in layout, and every (well, almost every) book having a subjects call on its main page.  Two major annoyances remaining about the system were (1) confusion between book- and subject-categories, and (2) if you went to the bottom of the main page of a book and clicked on a subject category listed there, you got a not-very-useful category rather than being taken directly to the subject page with all its really cool DPLs.  And this year both of those problems have been fixed.


 * So, where does your idea fit in to all this? Well, now that I've set out all that background, three thoughts come to mind.


 * It would be possible to simply put content onto the subject page using a  directive, for example putting some arbitrary material such as a tree at the top of the page above the subject page template call, so it would appear on the subject page but would not interfere with the other pages that query the subject page.  However, that means it wouldn't appear on the subject category page either, defeating the intent that when you click on a subject category at the bottom of a book's main page, you get a complete replica of the subject page.


 * It would also be possible to add one or another parameter to subject page, either to simply change the color of the background on the description area of the table, or to add some arbitrary material above the table (with the same effect as a noinclude block before the template call, except that this way it would also be replicated on the subject-category page).


 * On reflection, though, we need to think carefully about how this can be squared with the concept of the subject pages. There is (as I think you alluded to) some value in having the subject pages uniform in structure; and, at a very deep level, the subject pages are meant to completely distribute all per-book maintenance to the books themselves.  This is a difficulty with your tree that had just flat-out failed to register on me when you started exploring the idea:  the tree apparently requires maintenance, and it's not clear how to distribute its maintenance.  The subject hierarchy as it exists now is configurable, but the configuration per-book is fully distributed to the books themselves, and the (extensive) automation goes into allowing this configuration to be fully distributed while propagating it through to what appears on the subject pages. There is, by the way, another conceivable approach to this sort of thing, something that has occurred to me in contemplating the conceptual weaknesses of Wikidata but that I do not &mdash; yet &mdash; have the wherewithall to implement.  If there were context-sensitive assistants available, something that I hope to achieve by building up from my wiki-markup-based dialog primitives (but that's going to take some building, and I haven't found time yet), one could have a central overview resource whose coordination with distributed resources is not automatic, but a semi-automated assistant helps to guide contributors through the coordination.  Possibilities arise that are impossible with full automation; and in this particular case, contributors to a particular book could be helped through changes to something like your tree that are more complicated than simply choosing a subject (though one could also imagine an assistant helping contributors to choose what subjects to list).


 * --Pi zero (discuss • contribs) 17:26, 28 October 2017 (UTC)


 * Hello,


 * First, thanks for taking the time out to discuss the issues; after all, it could be argued that consensus arises when apparent contradictions are realized to be none.


 * Regarding the issue of subtemplating, I do not criticise subtemplating. Rather, I meant to criticise the way that it's been done on the given page, and the naming conventions. For instance, I'm not sure whether if it's intuitively clear what a "core" template is, even though when one dives into it, one will eventually find out, of course. But aesthetic reasons dictate to have it named in the most precise way. The same goes for the "robox" template.


 * Thanks for explaining the bit about in-book maintenance. I agree that some subjects are poorly maintained. However, the mathematics page is a long-term project of mine which has now accelerated and will probably boil down to me working on many different wikibooks, since every day I'll just visit the part of mathematics I feel temporarily interested in. Still, a solution to the issue that I see is this: There could be subject pages, but one could still allow for bookshelves where they are properly maintained, so that overviews as I did one have a place.


 * I've also been thinking about more, inspired by your suggestions on automation. The university level mathematics wikibooks are interconnected via links that reflect the semantics of the connections: Namely, when a theorem or a definition from an earlier (ie. higher in the tree with a connection) wikibook is invoked, there will be a link to that specific theorem or definition in that (earlier) wikibook. From this information alone, the dependency tree could be built by a wikibot in full automation. There would be no need for manual editing. Namely, a wikibook has an upward connection to another wikibook of the same subject if and only if it references some of its material.
 * In this fashion, one could build dependency graphs for each subject page in full automation, and this needn't be restricted to the subject at hand, but could be generalized to geography, literature, philosophy, and so forth. The downside of course would be that this construction is a priori not modular, so that one has to think about how one would handle sub-subjects.


 * The white background would be of relevance to people with poor eyesight. I would even suggest to let all subject pages have white background, and to get rid of most of the margins, replacing them simply with titles, without separators.


 * Finally, I'm not pinging you since you stated that you have talk pages you posted on on your watchlist. --Mathmensch (discuss • contribs) 17:52, 28 October 2017 (UTC)


 * Yes, this is on my watchlist. (I need to give other things my attention for a while now, and give myself time to think over what I want to say next.)  --Pi zero (discuss • contribs) 19:38, 28 October 2017 (UTC)


 * Some thoughts; not final ones, but trying to explore forward a bit on various fronts.


 * The subtemplate names in some cases are a bit generic, "/core", "/core2", etc. I'm not sure if the advantages of changing it are worth the trouble, but admittedly those generic names would presumably have contributed to your confusion and your negative impression of the way tasks are decomposed between subtemplates, so that's a reason to want better names, right there.  I have gotten into the habit, generally, of including in the documentation of each template a subsection on "Internals" where I explain something of its relationships with subtemplates (in this case, Template:Subject page/doc).  I actually think in this case the division of tasks between template and subtemplate is very natural:  the outer template figures out what's wanted, the inner template does the complicated page layout which is by far the most elaborate of the things that might, under various circumstances, be called for by the interface logic of the outer template.  The name of template robox is a legacy from well before I got involved, and it's a problem of a different order, too, because it's not a subtemplate but a standalone so the (imho bizarre) name isn't softened by being merely a suffix within a suite.


 * I don't think "bookshelves if properly maintained" works as a concept. A type of resource needs to either be there or not; people need to be accustomed to its being there or they're not going to look when it is, plus how and by whom is a decision made whether something is well maintained, given that if it isn't that's like because of a shortage of people around interested in putting time into it whereas deciding whether it's well maintained is yet another time sink. At the same time, I'm concerned that putting non-standard material (like that tree) on a subject page might both make the tree unlikely to be seen and make the usual content of the page harder to find.  I admit I'm not yet seeing the natural way through on this.


 * I dislike full automation. If there were a way to coordinate things so we didn't need any bots at all, I'd like that.  I can at least see the general shape of how semi-automation, if I can bring it to a higher state of development, might take over some of the tasks that tend to go to bots.  I don't insist we'd ever be able to do without bots altogether, but I do think human judgement gives a vital quality to things that automation can only leach out, and I see that vital human touch as ultimately the whole point of wikis, so that when we can shift things toward the human side we should, and when we're tempted to shift things toward more automation we ought to rethink.


 * A revision, perhaps something of a simplification, of the subject page format could be of interest.


 * --Pi zero (discuss • contribs) 20:14, 31 October 2017 (UTC)


 * I would like to say though that my diagram serves a very useful purpose: Namely, it clearly indicates a "path of learning" that one might take in the course of obtaining a mathematical education. (Besides, it is also extremely useful in order to find a particular theorem very quickly.) Hence, I would say that removing it would be a net loss for the project. I disagree somewhat with your criticism of full automation; a well-programmed bot can, at least in the mathematics case, create the desired subject graph that I now did manually. Please don't throw it away just because of a percieved general flawedness of machines and the bookshelf concept. Besides, Wiki guidelines explicitly state that there is a certain degree of freedom when it comes to subject pages. I think the diagram is useful, informative and aesthetically pleasing, and should be included, independent of whether any automation is implemented. I believe that the diagram displays the subject much more effectively than the automated subject page ever could.


 * I'm not sure whether we are on the same page in template programming; I would only get into it if I can be certain that there isn't somebody who's discontent with all my modifications. If I were to rework them, I'd do so as indicated: Give some better names, and shift "robox" to "box" and change some parameters.--Mathmensch (discuss • contribs) 20:50, 31 October 2017 (UTC)


 * Let me also say that I'm very keen on code efficiency and neatness, in ptic. indentation. --Mathmensch (discuss • contribs) 20:52, 31 October 2017 (UTC)


 * Clarification: I like the diagram, and have not had any intention to argue against it.  I also like the resources we are now providing on the subject pages.  The question, as I see it, is how to deploy the various desirable resources available to us in a way that works well all-around, and this is what I refer to when I say "I'm not yet seeing the natural way through on this."


 * Something I find annoying about templates is that there is, afaik, no easy way to find all the places that actually use a parameter, unless one sets up the template to automatically add pages to a hidden tracking category when they use such-and-such parameter; which makes it hard, in turn, to judge the consequences of tinkering with a parameter. I suspect if you and I could come to a mutually satisfactory plan on modifying, say, subject page, we could safely consider ourselves a quorum.


 * In most contexts related to wikis, I'm a lot more relaxed about efficiency than I used to be. I recall someone (probably bawolff) remarking, on some matter about the efficiency of doing something one way or another in javascript, that if you care about efficiency and you're using javascript, you're doing something wrong. :-P  --Pi zero (discuss • contribs) 22:43, 31 October 2017 (UTC)

We haven't resolved this yet, and I haven't forgotten. The status quo doesn't work; the page as it now exists is preventing our subject infrastructure from working right. I'm thinking a part of a solution is to keep the tree on a different page, and transclude it to whichever place-or-places we want to use it. Which still leaves the quesition of where to use it. --Pi zero (discuss • contribs) 16:00, 11 November 2017 (UTC)


 * As a matter of fact, unfortunately I realize now that I will need a more general diagram, since if I want to treat rings of sets (which would necessitate using basic ring theory in the set theory wikibook), I'll have to refer to the ring theory wikibook in the set theory wikibook, which would create an upward dependency, so that the diagram I would need has support for directed edges, that is, would support digraphs. (Of course, if any competent admin would like to import such a template, I should be most delighted.) But even as though this may not be possible yet, for me the given tree is a wonderful overview that makes editing so much easier for me, and I suspect that in a similar fashion, browsing readers will find it wonderful for navigational purposes. I still believe that the tree is one of the very best ways of organizing a subject page, and will remain an advocate for it. However, the necessary modifications for the subject infrastructure to work right should be made.


 * Also, it may well be that when the mathematics project progresses, there will be need for sub-subject pages for specialized areas of mathematics. --Mathmensch (discuss • contribs) 16:44, 11 November 2017 (UTC)


 * I approve of the tree concept. It ought to be a valuable resource if we can get the presentation/placement right.  I'm honestly unsure whether that placement will turn out to be the subject pages.  --Pi zero (discuss • contribs) 22:47, 11 November 2017 (UTC)


 * Suggestion. The subject pages aren't the right place for the tree. The system of subject pages is an integrated whole, in their interface as well as in their technical interconnections:  the point is to have all of those pages provide the same interface, uniformly, which is not consistent with one of them providing this tree instead.  At the moment, the tree is also preventing the technical devices from working right, with the result that the books filed in that subject should be failing to appear in ancestor subjects. So, would it make sense to put the tree on the subject category instead?  That would leave the subject interface intact, and would not break the technical infrastructure either.  --Pi zero (discuss • contribs) 01:57, 4 December 2017 (UTC)


 * I would like to have the tree at a place where it is visible and a sensible guideline to the readers. Since the main category link displayed on the bar at the bottom of the page is the subject page, I'd assume that the subject page is the ideal placement for it.


 * The more general diagram may be realized, as I have realized, by dotted lines. --Mathmensch-Smalledits (discuss • contribs) 16:25, 7 February 2018 (UTC)


 * Library Stacks (8145376020).jpg I do understand (so I believe) your desire. As an analogy, consider an old-fashioned physical library.  Stacks of books (I'd somehow half-forgotten how much I really love spending time in library stacks, places like [image to right]).  An old-fashioned physical card catalog, banks of drawers of 3-by-5 index cards.  And you've got a really cool tree diagram on, let's say, a legal-sized sheet of paper.  What do you do with that sheet of paper?  Everyone who sees it agrees it's nifty.  There's no way it'll go into the card catalog.  Maybe you could put it up somewhere in the stacks, attached to a bookcase or a wall?  Which brings up a lately under-appreciated property of pre-eletronic information storage technology: it has context.  Electronic forms lack context.  You aren't in a physical room where there are other books around the one you're looking at.  You can't even flip idly through the pages of a physical book.  I used to learn all sorts of interesting things by browsing bookshelves, and browsing card catalogs, and flipping through the pages of books.  --Pi zero (discuss • contribs) 17:43, 7 February 2018 (UTC)


 * ...which means that we've got to think by analogy: The analogue to a wall would be a "digital place" where everyone can see the nifty diagram. It's not just that it's nifty, but it provides the dependency graph by which a student can navigate where to start and what to learn. I'm putting it to you straight because I know that I can talk straight to you, without you getting the impression that I would undermine any authority. But there are certain analogues in the digital world to the real world, and in particular when it comes to visible places (the advertising industry is making a living out of this, without my approval). --Mathmensch (discuss • contribs) 20:29, 12 March 2018 (UTC)


 * What do you think? --Mathmensch (discuss • contribs) 11:59, 24 March 2018 (UTC)


 * (Btw: I am carefully leaving this pending in my notifications, so I won't forget to attend to it when I come up for air after my current clog of queued wiki tasks.)  --Pi zero (discuss • contribs) 11:17, 25 March 2018 (UTC)


 * Well, one thing I think is that there really isn't a strong analogy between the digital world and the real world. At least, so far there isn't.  All we see of the digital world is through a very narrow window (it's almost like looking at the digital world through a keyhole, but the metaphor of a small window will do).  Even if we're reading a digital book, we look at it through a window.  The real world is immersive; the very concept of bandwidth scarcely applies, when it's just all right there.  (I'm struck by this every year around July 4:  no matter how big a big-screen TV you have, watching a fireworks display on such a thing isn't remotely like the experience I remember from actually attending one in years past, sitting in a dark field with people seated on blankets all around me, while fireworks burst overhead, feeling the concussion wave in the air, seeing the sparkles fill half the sky, smelling a distant whiff of gunpowder.  As I said:  immersive.)  Reading a physical book is an infinitely richer experience; flipping pages, for instance, simply has no effectively analog in the experience of a digital book.  The term "desktop" for a computer display isn't nearly as accurate as "window", because it lacks the implied distancing and restriction of a window; a real desktop, like a real book, is immersive.  And browsing on Wikibooks versus in a physical library is like the difference between watching a fireworks display on TV versus being there; there's really no comparison. So, where do we go from here?  I see two paths, though in the long run we can explore both.  We can simply accept that web browsing is a very, very low-bandwidth activity, and flowchart how we would want the tree to relate to other pages on the site.  Or we can try to imagine how to make the experience truly immersive; can it be done with current technology, or should we be thinking ahead to anticipate what sort of technology would be needed?  --Pi zero (discuss • contribs) 17:29, 29 March 2018 (UTC)

The point is this: The diagram that I've created will help the beginner to learn mathematics as follows: Mostly by moving from the top down, she can discover the mathematical subjects one by one, sorted by dependency. That is, it will usually not be necessary to read up something, but rather the diagram represents a complete course in elementary mathematics. It is, or rather, will be (when all Wikibooks are complete) a good guideline on how to proceed. Hence, I suggest using the low bandwidth that we have to capture the essentials: The guiding line that will lead the pupil through a good mathematics education. --Mathmensch (discuss • contribs) 18:15, 29 March 2018 (UTC)
 * The question is how to connect things together. Here's a suggestion.  You are essentially creating a book series.  (There is no reason, in principle, why there mightn't be multiple books on any of the particular subjects shown in your tree.)  So, perhaps what you want is a book series template.  Of some style or other.  --Pi zero (discuss • contribs) 21:36, 29 March 2018 (UTC)
 * That would be much too small, if it's comparable to the other book series templates. Currently, when I begin to browse Wikibooks and start at the home page and click my way to "Mathematics" and then to "University level mathematics books", I end up finding myself staring at the subject page. Thus, one might really think about whether it is best to have the subject tree there. Alternatively, one could think about giving the page University level mathematics a nice descriptive name (such as "Order of the mathematical subjects" or "Dependencies between the wikibooks") and somehow giving a link to it on the subject page. This might require to extend the subject page template. (At any rate, the guidelines seem to allow for this; they are not particularly strict for subject pages.) --Mathmensch (discuss • contribs) 06:09, 30 March 2018 (UTC)


 * As to how to connect the books to each other, I'm thinking about including a "next" and "previous" section, which could also be in the form of templates (of course there would be several choices for Wikibooks that could be read next, and instead of "next" a better title might be "where from here" etc.). --Mathmensch (discuss • contribs) 06:10, 30 March 2018 (UTC)


 * Clarification. I was not suggesting the tree would go in the template; I was suggesting the template as a possible means to link each book to the tree page.  Though just what one would want the template to look like is then an interesting design challenge.  It's also possible one would want the tree to appear differently depending on which book one went to it from, which might be accomplished by various means; one might do something using anchors, and perhaps dialog.  --Pi zero (discuss • contribs) 06:53, 30 March 2018 (UTC)

It is clear that this debate has to come to its conclusion eventually. Hence, I propose the following consensual solution: If that sounds acceptable, please let me know, and I will implement it. --Mathmensch (discuss • contribs) 09:56, 3 June 2018 (UTC)
 * 1) The University level mathematics page is left there as-is, for me and the readers to be able to find the book they need
 * 2) The subject page contains, at a clearly visible position, a link to the subject tree, so that surfers are led to the place where the collection is sorted in the most understandable and intuitive way
 * 3) There will be a template linking each book (and possibly, each chapter) to the tree
 * The cataloging parts of the project infrastructure evolve, very slowly, over time. Atm I'm in the process of migrating the entire subject hierarchy into a different form, "shelves" contained in, formally, a "book", and I expect that process to take at least months to complete (it needs to be done slowly and carefully, as there is much design work involved) &mdash; it's the latest stage in an infrastructure overhaul that's been underway for just under two years so far.  Whatever precise tactics we use for your tree atm, it's reasonable to expect possible evolution over large time scales. There is, I noticed, at least one case where a subject page has a subpage with additional information on it.  I forget whether that's come up in our discussions.  --Pi zero (discuss • contribs) 11:45, 3 June 2018 (UTC)
 * Ah, here it is. Linked from its parent page, Subject:Electrical engineering.  --Pi zero (discuss • contribs) 11:51, 3 June 2018 (UTC)


 * First: Sorry for the ping, I forgot. Second, is there any page that explains in more detail what your new infrastructure is going to look like? Or otherwise, could you briefly get into a bit more detail? I obviously need to know in order to be able to foresee what kind of a solution would be adequate. --Mathmensch (discuss • contribs) 12:36, 3 June 2018 (UTC)


 * The new system will look pretty similar to the one preceding it, with three differences.
 * Nomenclature. This is what really forced the change.  The current pages are called "subjects", and are in the   namespace recognized by the wiki platform.  We are preparing to set up categories that classify pages of books as well as books themselves, and so we needed to shift the pre-existing categories to a name that would clearly identify their function separate from the new ones.  Therefore the pages that have been called subjects will have name prefix , or for the top-level ones,  .  (Technically, these prefixes are not recognized by the wiki platform, so the pages are in mainspace, which is fine; they are assigned by BookCat to book Wikibooks Stacks.)  Eventually I'll have shelves for all the subjects and all our books will be in both the subject and shelf hierarchies; and at that point I'll be able to do the equivalent of switching a big switch, and all the books will be visibly on shelves instead of in subjects, and then it'll be time for me to start the (still protracted) process of mothballing the old subject pages.
 * Internal workings. The automated stuff that drives the subject hierarchy doesn't work as well as it should, and with years of additional experience, plus the handy tool of template evalx, I'm imporving that stuff while I'm at it.
 * Semi-automated assistance. The subject hierarchy has a weak form of semi-automated assistance built into it, using templates, to aid human beings in curating the hierarchy.  I'm improving on that a little, and I also plan to introduce some dialog-based semi-automated assistance.  I'm hoping to get some valuable experience from that, into how to do dialog-based semi-automated assistance.
 * --Pi zero (discuss • contribs) 19:02, 3 June 2018 (UTC)


 * If I understand correctly, then there may be one book on several shelves? --Mathmensch (discuss • contribs) 07:35, 4 June 2018 (UTC)


 * Yes. --Pi zero (discuss • contribs) 11:41, 4 June 2018 (UTC)

A few doubts
I have a few doubts in mathematics which I wish to discuss with you. Is there a way I could contact you outside Wikibooks (considering that discussing doubts in the talk page looks odd). Thanks. Leaderboard (discuss • contribs) 19:12, 10 June 2018 (UTC)
 * I've just unlocked the e-mail feature. Feel free to send me one! --Mathmensch (discuss • contribs) 20:41, 10 June 2018 (UTC)
 * Thank you, I've just sent one to you. Leaderboard (discuss • contribs) 04:33, 11 June 2018 (UTC)

Commutative Algebra
What is the status of this book? Is it to be deleted, or what? (I'm asking particularly to help figure out what to do with its book category which is now flagging itself for operator intervention.) --Pi zero (discuss • contribs) 09:04, 27 June 2018 (UTC)

i'm in the process of figuring out what of it works in the non-commutative context. Its current contents will be split up and augmented in the following books: I emphatically ask you not to delete the book, because it serves me as a reminder of what to do. You may move it to a place you deem appropriate, given that I can access it there. --Mathmensch (discuss • contribs) 11:25, 28 June 2018 (UTC)
 * 1) General ring theory
 * 2) Commutative ring theory
 * 3) Linear algebra over a ring
 * Ah, I see, so it's in the process of being chopped up and redistributed elsewhere. --Pi zero (discuss • contribs) 11:54, 28 June 2018 (UTC)
 * Seems to me we want
 * a label on the book so that users who come across it know what they are look at and
 * categorization of the book so its still-existing pages are tracked within the project infrastructure.
 * I've adjusted the book main page for those things. Note that without a status tag, the book is listed under "Unknown completion".  --Pi zero (discuss • contribs) 12:04, 28 June 2018 (UTC)