|Perl: the Markov chain saw|
Thank you ELISHEVA for putting this together, and ++.
I can't offer any doctrine but I do have some personal views on some of the ideas we're exploring here.
First and foremost, I vehemently disagree with those who feel we should change the "look and feel" of the Monastery, in pursuit of something "flashy" or "modern." "Don't fix what ain't broke" is valid advice to those who concern themselves solely with appearance. Being au courant is perhaps a good thing if one is peddling widgets, but it requires an unnecessary investment for a community dealing in knowledge, like this one. Further, being "up-to-date" (another phrase often used by advocates of a new look) is transitory. Today's up-to-date is tomorrow's passe.
And if "up-to-date" or "modern" means AJAX, Flash, fancy graphics, and so on, using those almost guarantees longer download times; not a major issue for those with reasonably high speed internet access, but a huge stumbling block for users who rely on (bottom-tier) satellite or dialup.
OTOH, I strongly agree that "content is king."
We might make PM's content a bit more regal, if we develop a mechanism for hiding worthless or off-topic commentary on threads of more than some agreed-upon age (30 or 60 days?), so that the reader of any older thread could be confident that what's initially presented is, by consensus of the Saints or some similar group, the gold standard answer(s). It probably wouldn't take a lot more effort to give visitors the per-thread option of also viewing ALL the nodes in the initial thread, but even that would not be trivial. Overall, though, such a mechanism would be complex to develop, even were we to come to a consensus that this is a "good idea" and consensus on who gets to rate something as "gold standard."
Markup? I suspect (but can't prove) that a large proportion of our newest users are more apt to have some passing acquaintance with .html markup than with POD markup.
Lack of markup: I suspect the only reliable way to cure the appearance of hopelessly unformatted nodes is to develop a procedure for distinguishing among code, data, and narrative and to then invoke that procedure at the "preview" stage of node creation. In my (perhaps unworkable) vision, if the procedure finds markup deficiencies, the "create" option would remain blocked and the author would be given a message about the identified deficiencies. Wash, rinse, repeat.
Accessibility for Beginners: As one who came here with no CS background, and little experience with what one might characterize as *nix-ish documentation (which, in my continuing view, is generally highly valuable for readers who already have a broad general grasp of any particular topic and unspeakably obtuse for the newbie), I found much of the standard documentation (perldoc -f ..., perldoc modulename) obtuse in the extreme.
Welcoming to newcomers? I'd stand this one on its head. How can we better help newbies to avoid the pitfalls that sometimes win them caustic corrections?
Duty calls. Stay tuned for updates!
Update: Upvotes in this thread will not necessarily reflect agreement with any particular proposal nor endorsement of that proposal's feasibility but rather will be cast for well-reasoned arguments.