Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??

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.
Today, some years later, I do appreciate how important it is for the newbie to learn to read such documentation, but I continue to believe the Perl community (and many others) could do far better than it does producing documentation for the innocent (not, not an "Idiots' Guide" but documentation that by structure and language serves as a foundation for further learning.
Our Tutorials section seems to me to provide a model; perhaps some of us should develop tutorials on topics even more fundamental than appear there now.

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?

If a neighbor wants to borrow my chainsaw (not allowed, period) or a cup of sugar, I expect that neighbor to make the request in accordance with some cultural norms:

  • Don't ring the bell at 2 a.m.
  • Don't suggest by the manner of the request that I have an obligation to respond affirmatively (and, especially, don't suggest that I should run to the store and buy some sugar so they can "borrow" it).
  • Explain clearly what it is they want to borrow. Asking for a "some sugar" fails my test of adequate definition in the request; asking for a cup of s white granular substance fails as to particularity (and reason).

If my neighbor were a newcomer to earth, and I were exceptionally well-disposed, I might manage a courteous explanation of how one or more of the above falls short of acceptable conduct on my doorstep. Otherwise, I believe that I'd be well justified in asking the would-be borrower to come back after 7 a.m. or with a more comprehensible request. And if said neighbor assumed that I owed him/her a cup of sugar just because that neighbor wanted it, I'd not feel at all badly about suggesting (forcefully) that the neighbor never darken more door again without having learned to distinguish between their wants and my obligations.

Yes, we sometimes are brusque or worse in response to an incoherent question or unreasonable request, but it seems to me that most newbies (well, those who stick around for a bit) tend to take the reasonably courteous correction quite well, and most demonstrate that they actually benefited from the learning experience.

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.


In reply to Re: Making Perl Monks a better place for newbies (and others) by ww
in thread Making Perl Monks a better place for newbies (and others) by ELISHEVA

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having an uproarious good time at the Monastery: (5)
As of 2024-04-25 17:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found