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: topics) Re: Lack of structure. Channeling structure
by kudra (Vicar) on May 15, 2001 at 14:00 UTC
|
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.
| [reply] |
Re: Lack of structure. Channeling structure
by jeroenes (Priest) on May 15, 2001 at 13:59 UTC
|
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) | [reply] |
Re: Lack of structure. Channeling structure
by Masem (Monsignor) on May 15, 2001 at 14:59 UTC
|
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 - mneylon-pm@masemware.com
||
"You've left the lens cap of your mind on again, Pinky" - The Brain
| [reply] |
Re (tilly) 1: Lack of structure. Channeling structure
by tilly (Archbishop) on May 15, 2001 at 16:43 UTC
|
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... | [reply] |
(jptxs) Re: Lack of structure. Channeling structure - index?
by jptxs (Curate) on May 15, 2001 at 16:23 UTC
|
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
| [reply] [d/l] |
Node aging, document structure: lessions from TinyWiki
by scrottie (Scribe) on Jun 14, 2003 at 09:38 UTC
|
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 | [reply] |
|
|