Lack of structure. Channeling structure

Lack of structure

I am agree with deprecated's Summing up recent ideas into a concept: Code vs. Prose, but I don't think the situation's so sad. Yes, there's a huge amount of prose respect to the code, but it's true that an encouraging portion of that prose is very high quality. What Perlmonks lacks is structure, and a way to prevent node aging. Good nodes (good prose and good code) are often forgotten.

XP system has often showed its fallacies. To avoid oblivion, we use the experience of older monks and the patience of those who collect in their homenodes or in appropriate nodes (like epoptai's PerlMonk Related Scripts) posts which they judge significative from some point of view.

Code-related problems remain. According to me, code isn't reviewed and improved as it deserves to be. At least, not always.

Channeling structure

I propose a solution for the two problems I mentioned. I know (well, I guess) that everyone that write a node does it thinking to its immediate utility. I mean, every node has its own function in the thread it has been inserted in (I'm not sure this is English: I will try to explain it better if someone will ask me. Please forgive me). Nobody writes his nodes thinking that they will be put on a bookshelf. But, as it happens for books in a library, nodes are commonly used as reference. So, what I propose is to organize groups of nodes as they were composing a book. Not truly a book, that is a bigger intellectual and editorial effort, but something that brings structure to the stuff that is on Perlmonks so far.

Such a job could have an interesting side-effect: a book such as I described needs code examples. For this reason we will be forced to review existing code and possibly to write new. This could be done in teams, allowing who is interested to write code while more experienced Monks review, comment it and suggest improvements.

Drawbacks: the first that rises in my mind is stagnancy. Everyone has a certain amount of time to spend on Perlmonks, and if he uses it to organize pre-existing material, he will not produce new nodes. I guess there are other disadvantages I don't see now.

I think we have a lot of interesting material: we could develop Perlmonks-books (in the sense I described above) for a large amount of topic such as:

• OOP and Perl
• CGI Scripts (obvious)
• Data Manipulation with Perl
• Human-Machine Interface with Perl

...and so on. What do you think about?

[kudra]

I like the idea of organizing nodes by their topic (chapter) as opposed to just the type of post (question, discussion, etc). I am not convinced that there is value in adding complementary content to link nodes together, however, or in ordering them relative to one another within a section.

I think the addition of a topic/chapter nodelet could be a solution to this. I see it as a series of checkboxes with the names of various topics, from the Q&A sections of arrays and regexes to turnstep's discussion sections like voting and customization. People over a certain level would have the option of putting a post in to a topic, or of removing it. Editors would have the option of adding new topics. This would only be applicable to root-level nodes--other nodes would inherit from their parents (which means any changes to the root node's section would require cascading changes through the thread, or else some information to be stored about an entire thread rather than just a node). Naturally, these would then be searchable categories.

It would also be nice to be able to explicitly list nodes which are not categorized, so that people scouring the archives to use up votes can also sort the old posts while they're at it. ;)

Update I was thinking of the keyword nodelet when I wrote this post but commented out my thoughts on that because I couldn't think of how to tie it in. So here it is, out of comments:

Better yet, let it replace the keywords nodelet! The keywords nodelet is pretty much useless. People just add random stuff that in no way helps with searching. But even if quality content was the norm, I think the keyword nodelet would be of minimal use as a searching mechanism. Supersearch already looks for words found in the node body, and any words which aren't found in the node but would be good search terms can be included in comments, which are also searched.

[jeroenes]

Some line of thoughts on the subject:

Of course, such books would be very nice. But I don't think we could write 'books' in the same, cooparative matter that we do so succesfully when writing nodes/node-trees. That's why one person should be responsible for one 'book'. Moreover, these 'books' would also serve as high-quality indici to the site. And these indici are badly needed, as a lot of high quality nodes are hard to find, unless you spent quite some time @perlmonks. In the latter case you now them and you'll probably have them in your personal nodelet already.

But to serve as indici/books to a certain subject, you need only a few of these subjects, otherwise you need to index the indici... So I would opt for a few of these 'books' aka 'collections', and make a list of wanted subjects. Persons than can subscribe (to prevent double work) to these subjects and make the collection, asking for help from others if necessary.

These 'books' should be of such a quality that they deserve their own section in the monestary. Maybe they can even make it to print at a certain stage.

Such a system would require a lot of work from the hand of the 'authors/editors'. Ppl however tend to spend a lot of time at the monestary, so I expect ppl are willing to invest time in this kind of editing (like epoptai when it comes to CB clients, or jcwren for the stats and more).

Monks mostly are specialized in one kind of subject more or less, so the books should be composed by the 'experts' on the subject.

One subject I would add to larsen's list:


• Coding: Methods and approaches

Jeroen
"We are not alone"(FZ)

[Masem]

Well, we already have a mechanism in place for grouping nodes: the Keyword nodelet. Right now, it's highly underutilitized, and would need a bit more additional functionality to make it work right. Namely, it should be up to the author of the node, as well as possibly editors and gods, to remove or modify keywords that are suggested by others. There would also need to be some way to search on keywords only as opposed to what is offered in Super Search. But using keywords effectively would make organizing the site in a meta fashion work much better than trying to add yet more functions.

---

Dr. Michael K. Neylon - [e-mail] || "You've left the lens cap of your mind on again, Pinky" - The Brain

[tilly]

I am still waiting for the wiki to land.

That will make it far easier to turn some of these ideas into reality without undue work on vroom's part...

[jptxs]

you know, I wonder if a book such as this is overkill, but if the index pages to such books wouldn't be valuable? Basically have an index of the site word for word. I know we can search, but I've always thought that a good index in a book has yet to be matched in power by any search engine in terms of getting immediate results.

I envision having listsings like:

eval(34,789) - 12334(3), 56789(23), ....

where eval is our word, the first number is the total amount of times it was found, then node_ids where it was found are listed one by one, with the number of times it was found on them. Maybe one could even make that index searchable so that you could weed out certian words to have a very short list of things to go through. Perhaps we could even have a separate index for just node titles and there there would be a count of how many times the word appears in the title and the body...

just the first thing that came to me reading this one =)

"A man's maturity -- consists in having found again the
seriousness one had as a child, at play."   --Nietzsche

[scrottie]

TinyWiki has some lessons here. It was created to house Perl Design Patterns, so the end goal is a book-like document. Like a Wiki or like the Everything Engine, it is composed of nodes. The standard Wiki idiom of category membership was barrowed, to good effect. The original Wiki, Ward's Wiki uses this. Wiki automatically creates links at the mention of a known compound word, and Wiki will tell you all of the pages linking to a page. By linking to a category index, people may link back from that category index to everything that links to it.

TinyWiki has an assemble.cgi script that attaches all referenced nodes from one node to the end of that node. Essentially, the starting node is the table of contents for a book, or a chapter, or some other document. It has no role but to list which nodes, and in which order, nodes should compose a book.

Recent edits has proven critical for Wikis as well. TinyWiki's lists all nodes last edits. This lets maintainers work both directions - update the least recently edited nodes and the most recently edited nodes - to bring things up to date or refactor them, and to answer questions and check peoples editorial work.

Refactoring is important. It is vital. An old page that duplicates the contents of a newer page may have the newer page merged in, or it may be merged into the newer page. Things are transient in a Wiki. Nothing is permenant. People contribute knowing that eventually their ideas are just fodder for something larger. In terms of an information system, redundancy is bad.

Cross referencing. Each new node links to related nodes by mention of keywords, but it requires attention from people who know their way around the site to edit old and new nodes and improve this cross referencing. If nodes don't link to related nodes, navigation is impossible. I find browsing Wards Wiki a great way to pass time, but leaving the beaten path of the home page on PerlMonks, and you're instantly in no-mans land.

Mechanisms help the process, but ultimately it boils down to, as Ward puts it, careful attention to detail.

-scott