Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Making Perl Monks a better place for newbies (and others)

by ELISHEVA (Prior)
on Mar 18, 2009 at 16:55 UTC ( #751522=monkdiscuss: print w/replies, xml ) Need Help??

A few weeks ago cosmicperl began a discussion about the pros and cons of a newbie focused satellite site for Perl Monks. The suggestion of a new beginners only site was not particularly well received, and instead triggered a large number of suggestions about how the current Perl Monks could be improved.

This is only one of many threads where suggestions for improving PM have been offered. In the coming weeks, I hope to construct a list of some of the more recent threads. I will also be reviewing them and compiling a list of suggestions that people have made for improving PM. If anyone else is interested in working on this, please make yourself known.

This process (and this post) is an outgrowth of the discussion we had last week on the thread Process for Site Improvement. We have at present no "official" wish list or mechanism for prioritizing suggestions for site improvement. In that thread jdporter suggested that for the time being, one way to get a better understanding of what changes matter to us monks would be to compile a list of suggestions from PM discussion threads.

Some of the proposals in PerlMonks for newbies? are very specific; some simply point out general areas where improvement might be valuable. I've assembled a list (below) of the various suggestions from that post in hopes of stimulating discussion on the following questions:

  • Which, if any, of these suggestions do you feel are valuable enough to merit further discussion?
  • Do you see a consensus developing around any of the suggestions?
  • What suggestions would you add that aren't already on the list?
  • What do you value most about Perl Monks and which of these suggestions enhance or build upon that?
  • Which of these have in fact been implemented but need to be better publicized?
  • As we work through other threads and gather their suggestions what is the best format for organizing them? Do we want to see other "per-thread" summaries? What about consolidating all suggestions into a single list?
  • If more that one person is involved in compiling a list of suggestions (and I really hope there will be), what tools does PM provide to help us coordinate our work?
  • How would you prioritize these suggestions? What is the best way to keep track of a developing consensus about which suggestions are highest priority? Is there a way we could adapt the polling mechanism? Is a qualitative summary the best way? Some combination?
  • To the members of cabal, and pmdev in particular: What would it take to actually implement the more specific suggestions - both technically and in terms of support from the wider monk community?
  • What would you be willing to do to help make your favorite suggestion "happen"?
  • This thread gives examples of suggestions, some clear and some overly general. If you were to write a How (Not) to propose a site improvement tutorial, what would it include?
  • Was the format of this post helpful? What would you do to improve upon it?

If there is no objection, when this thread winds down, I will summarize the comments here and post the results so that we can continue to build on the discussion.

Best, beth

Note 1: My apologies in advance if I left out anyone's suggestion or misrepresented their views. If I have done so, please message me and I will make the correction.

Note 2:Many thanks to all those who gave suggestions privately and on the thread Process for Site Improvement about how to go about this task. They made this thread possible.

Suggestions have been grouped into one of the following categories:

Site look and feel suggestions

Site content and navigation suggestions

Community building suggestions

Site performance suggestions

Site development tool suggestions

Places to look for further inspiration

  • Comment on Making Perl Monks a better place for newbies (and others)

Replies are listed 'Best First'.
Re: Making Perl Monks a better place for newbies (and others)
by ww (Archbishop) on Mar 18, 2009 at 22:04 UTC

    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.

      Well said, and we are in agreement, for the most part. Except for the appearance issue, on which I'd just like to address three things here.
      1. The desire to improve the site's appearance doesn't arise from a concern solely with appearance. It arises with a concern that appearance should be at least considered, rather than dismissed out of hand because content is more important (which we are in complete agreement on). If changing the appearance were to degrade the quality of content in any way at all, I would be totally against it. But I think it's possible to have both.
      2. You're right, what's current now will be passe in the future. But that's part of the problem: The fact that the site doesn't change is noticed. It makes it look like nobody cares enough, or that the site is not important enough, to warrant having its look-and-feel updated every few years. Also, "if it aint broke" is an irrelevant argument to the newcomers unfamiliar with the community. The site just looks like it's old and nobody cares. That's incorrect of course, but I feel that's the impression that's made.
      3. Making the appearance modern does not require flash, "fancy" images, or AJAX. The default site already loads an image largely for humour value. That same bandwidth could be used for a sprite table, rendered using CSS (just for example). It does involve taking into account best practices on usability that have been developed over the years. If you've read Steve Krug's Don't Make Me Think, it should be quite apparent that this site, in fact, requires quite a bit of thought. That might have been the norm in the late nineties, but not anymore. As I said, the actual process of streamlining would take some effort, but I think it's at least worth considering.
      That's my $0.02. When all is said and done, this isn't the most important thing to address out of this thread by far. I think more functional and content-oriented ideas should have more weight, but I wanted to make my position more clear.
      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.

      I must say that I disagree. Look and feel has a huge impact on the usability of the site. Also, improving the layout is not fixing. A modern looking site does not have to compromise the content in any way. I have to admit though that the designing of the PM user interface does require vision, skill, time and thought and can not be considered to be a simple task nor for the faint hearted. Making PM a better place is a worthy target and it should be the aim of every monk.

      I also strongly vote for adding more markup and linking information on the node editing page. It's cheap and easy to do ;-)

      seek $her, $from, $everywhere if exists $true{love};
Re: Making Perl Monks a better place for newbies (and others)
by bellaire (Hermit) on Mar 18, 2009 at 19:50 UTC
    Nice write-up, and thanks for putting the effort forth to compile this list, I know it can't have been easy. I'd ++ multiple times if I could.

    First, I have some meta-commentary on the problem of dealing with suggestions in the first place. It seems like most of these suggestions can be broken down into two groups:
    • Suggestions for site features, i.e. things that must go through pmdev.
    • Suggestions for content or community behavior, i.e. things that could be done at any time, if enough people care enough to go ahead and do it.
    Unfortunately, it's hard to build consensus on these issues. I think that part of the problem is that the suggestions themselves are buried in various threads (for example, this one and the node from which this list was compiled). Even when they are found, it's hard to know whether they have been acted upon, superceded, forgotten, dismissed, or whatever. Case in point, the recent addition of support for [man://] markup, which was requested, implemented, forgotten, requested again, and then applied. Handling suggestions like a forum makes them difficult to find and to manage. Compiling this list in the first place is a good start, but I sense that it's going to be hard to extract consensus from the discussions, even given the current voting system. For example, many of the suggestions discussed have both proponents and detractors. Even if the pmdevs wanted to use these nodes as a basis for deciding what to work on next, they would have a hard time making sense of the discussions. In the end, things remain as they are, that is, the pmdevs work on what they personally feel is appropriate, and the gods make a further judgment on whether their efforts, once submitted, are realized on the site.

    I really don't know how to deal with this. On some other sites, there is a voting system attached to suggestions. This way, developers and admins have a clear idea of what the community wants. They don't have to search through discussion threads, mentally summing the votes for and against at various depths, or trying to interpret people who are presenting two sides of the story. Something like that would be nice, but of course that in itself is a suggestion that would require an implementation in code, unless somebody wants to pony up the cash to pay for such a service.

    The other idea I have is that there could be a new order of monks, whose job it is to solicit, facilitate, and compile suggestions for improving the site (much as ELISHEVA has already done in this thread), and do this on a continual basis. Unfortunately, since they would have no abiltiy to actually do anything about it, they'd be limited to publishing their findings as a new root node every so often. The pmdevs and the gods could take those data or leave them, as they see fit, but at least the information would be marshalled for easier consumption. After several weeks of demands for some form of WYSIWYG support (for example), perhaps they might decide it's worth looking into. Deciding the mandate for this proposed order definitely would require some extended discussion.

    Second, to address some of the specific suggestions made, here are my thoughts:
    • "Pretty sites", the "dated" look, and ease-of-use - The site, even in the default (public) view, is cluttered. Content is king, and must trump other factors, but there is no reason you can't have both an attractive, modern presentation, and the same excellent content we've grown to love. Actually accomplishing that will take effort, and I'm not sure that anyone wants to put in that effort given the objections that have been raised by the people who find nothing wrong with the look and ease-of-use. In particular, why not simplify the view that the general public sees, while leaving alone the baroque complexity of the interface for established users?
    • WYSIWYG and simpler markup - I don't particularly agree that WYSIWYG is itself a good idea, however at the very least I don't see why a more comprehensive summary of Markup in the Monastery can't be presented on node editing page. Also, non-WYSIWYG javascript support for editing markup of various types has been around a long time in heavy use elsewhere on the Internet. It should be possible to set up a non-buggy solution.
    • Preview nodes on update and for chatterbox - Especially for updates, seems like a great idea. I was actually somewhat bewildered when I discovered its absence there.
    • Content for Newbies - Not sure here. I think part of the problem is that there is so much great content already here, it's hard for newbies to know what they should be looking at. So, in that respect, a prominent "Start" node (if you will forgive the reference) would be a good idea.
    • Site Promotion Suggestions - I think that promoting the site by itself won't have an effect if the experience people have on arrival isn't improved. Going back to look-n-feel, the "new generation" of programmers see no reason for this site to have its decade-old appearance. It gives the impression that the site is a relic. If that were to change, site promotion could be quite effective indeed.
    • Community Building - I totally agree, I just am not sure what exactly to do. :) Twitter is a good start (and I just started following PerlNews, which I had no idea existed until this thread).
    • Performance - It seems to be the elephant in the room, which gives me the impression that nothing can be done. I don't want to be struck by lightning for even asking, so... moving right along...
    • Development Tools - I don't know enough about the existing tools to comment here.
    I think that's enough of me talking now.
Re: Making Perl Monks a better place for newbies (and others)
by mr_mischief (Monsignor) on Mar 18, 2009 at 22:05 UTC
    There is a certain risk one takes when skimming for material rather than reading for comprehension. It seems you've taken my discussion of TinyMCE out of context here.

    What I actually said was:

    TinyMCE might actually improve a few things for a few people. However, most of its utility would not be useful for a PM-like site. It requires additional complexity in the node editing pages. It takes additional bandwidth to serve the JavaScript for it. The best feature of TinyMCE for a site like PM is the automatic paragraph breaks, which are easy to do in the code for the node engine.

    This was in direct response on a point-by-point basis to cosmicperl's assertion that "Easier to use interface (TinyMCE)" was a goal for a site friendly to new users.

    I specifically stated that while TinyMCE might be some help (the part you mention here) that most of the features it offers would not be useful here. Most of the complexity, therefore, would be for not much benefit. The best feature, as I said, of TinyMCE for a site with text content such as PM would be automatic paragraph breaks. I even mentioned that would be simple to do in the node engine without any JavaScript. Slashdot for example has a mode in which two consecutive newlines get straightforwardly translated into a paragraph break.

      "...automatic paragraph breaks, which are easy to do..."

      I found this thread because I searched for "paragraph breaks".

      Posting from a tablet or phone, (something I do more and more frequently these days) and inserting code for paragraph breaks on a touchscreen keyboard is like, a nearly intolerable nuisance. I don't like Tiny MCE, please no, but converting text newlines to html paragraph breaks is a trivial substitution.

      I'm not exactly a "newbie", though, historically I post very infrequently, I thought, perhaps it was thought that forcing people to insert a minimum of HTML into their posts will be educational or something. I don't know.

      But now, to make this posting more readable, I will need to navigate down into the deep recesses of this bloody tablet and find the left angle bracket, navigate back out, through several layers of keyboard functions to type in a p. Dive back down for the right angle bracket, do the same steps for the end paragraph, including the forward slash this time. Copy these to clipboard and go back through my post and paste in paragraph breaks. All of which takes more time than it took to write the post itself.

      If I were going to post here often, it would probably be easier to hack my tablet or phone (both Android) and do something with the keyboard layout to include some basic HTML. Maybe there is an app for that? Sometimes on my phone I see a .com key.

      Now time for another grueling exercise in constructing html paragraph breaks. (On my computer, typing html is second nature, but the angle brackets are actually on the keyboard!)


        I agree that needing to add your own HTML markup is a pain. However my experience with a number of other forums where a WYSIWY(almost never)G is provided has convinced me that PerlMonks' actually has landed in the right place by placing the smarts on the far side of the keyboard.

        For reasons I can't fathom every online editor I've used offering more than trivial markup gets it wrong, especially when trying to handle a mixture of prose and code. Some make it almost impossible to post something and have any idea at all what it's going to look like. Even big players like Google can't get simple editing right.

        PerlMonks seems to get scorn poured on it for "looking old". Maybe, but I find it much easier to navigate than any other similar forum I've used - bar none! I use Recently Active Threads as my "home page" and open threads I'm interested in reading in a separate tab. In my opinion the sideways tree view makes the flow of conversation much easier to follow than any other forum I use.

        Yes, it would be nice if it were easier for noobs to enter nice posts, but for the most part a poorly formatted post is a great heads up that the OP has applied laziness in the wrong way.

        I consider for the most part PerlMonks ain't broke, so please don't "fix it"!

        Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
        I wrote Wikisyntax for the Monastery some years ago, this might be of help for you.

        Most of my posts are written on mobile and I almost never need to type html markup.

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

        I don't believe that in March 2009 when I wrote my reply so many people were using their phones and tablets as primary Internet devices. Still, I think a markdown or similar wiki-friendly input method would be worthwhile.

        Even if the site just added links for URLs and auto-added paragraph tags for consecutive newlines it would be nice. We'd still need a way to denote code, and I like PM's way generally more than, say, Reddit's.

        But now, to make this posting more readable, I will need to navigate down into the deep recesses of this bloody tablet and find the left angle bracket, navigate back out, through several layers of keyboard functions to type in a p. Dive back down for the right angle bracket, do the same steps for the end paragraph, including the forward slash this time. Copy these to clipboard and go back through my post and paste in paragraph breaks. All of which takes more time than it took to write the post itself.

        Make yourself a template ;) I keep mine in my clipboard , something like

        <p><i> </i> <p> <p><i> </i> <c> </c> <p> <p> [mod://]] <p> [cpan://]] <p> [dict://]] <p> [wp://]] <p> [href://]]
Re: Making Perl Monks a better place for newbies (and others)
by ig (Vicar) on Mar 19, 2009 at 22:17 UTC

    I wonder if an RT queue might be a good tool for keeping track of requests and suggestions. It works well in other contexts and requests could be linked back to nodes on PM for discussions.

    A few items from my wish list:

    • I too wish there was a preview on the update page.
    • I wish there was a preview on the scratchpad edit page.
    • I wish there was an easy way to find responses to my own posts. An optional filter on Newest Nodes so that it only showed nodes in threads I had posted to would be very nice. A count of responses on the list on Perl Monks User Search would also be helpful.

    update: actually, there is a preview on the scratchpad edit pages - I just didn't see it because I never thought to look down for it instead of up top where it is on the comment edit page, and it was always just off the bottom of my screen.

      While wishing, may I/we have some sort of killfile feature please? Such a feature would allow to avoid display of nodes based at the very least on title (regular expression, possibly length) & author; if feeling generous, possibly on the length of the body if not content (regular expression based).

        Hiding all posts by an author can be done through CSS, by using for example the .pmnote-5348 rule to highlight or hide all posts by user 5348. We Stylin'! and PerlMonks CSS HOWTO also contain CSS references.

Re: Making Perl Monks a better place for newbies (and others)
by harangzsolt33 (Friar) on Jan 31, 2020 at 04:55 UTC
    I apologize in advance if I am posting this in the wrong place. I started learning perl in 2016 on my own. When I found the PerlMonks website, I decided to join, because I saw that the site was active. Questions got answered. And the answers were very valuable and helpful. Beginners were not made fun of. I loved the community-styled of the forum. And I also liked the simplicity of the website.

    Many sites on the web take a long time to load, because they use various complex JavaScript modules. Many times I found myself reading PerlMonks with my old phone, which of course, has an old web browser called Microsoft Internet Explorer 11. It cannot be replaced or upgraded unless I buy a new phone. Some sites tell me "This site does not support your browser. Please upgrade your browser." and some sites even block all content, so I can't see anything other than the warning message. That is pitiful. JavaScript is mostly used to display ads, and sometimes it's used to display animations which are unnecessary. I hope that PerlMonks will not become one of those flashy sites that will show up incorrectly on older devices. Right now it's pretty good.

    When I first joined PerlMonks, I had a hard time understanding the hierarchy of the site. It took me a while to figure out how to post a question. But I figured it out. I have to admit, there are parts of this site which I never use. And there are parts that I use very often. The site presents a lot of information, and most of it I overlook. When I visit the site, my eyes focus on the questions and answers. I also like to see who's online at the moment. Going backward is a bit tricky. I am still not sure how many arrows I have to click on to see the previous page of questions. So, navigation is a bit hard, but you can get used to it.

    Yahoo! has been completely redesigned from the ground up when Marissa Mayer became CEO. The new design, however, was a total failure, and a lot of people stopped using Yahoo. Everybody KNEW how to use the old Yahoo, but after the new design, nobody could find anything. Navigation was totally changed. Everything was different, and a people just became frustrated and left. So, sometimes no change is the best policy. Too much change forces people to have to relearn everything. I hated it when our local Walmart Supercenter decided that they are going to reorganize the whole store. They changed everything. Earlier I could walk into the store and find immediately what I was looking for. And then, I had to spend half an hour looking for stuff. When I asked the employees if they know where I can find such and such item, they didn't know either. But that's often what happens when you redesign something or redo from the ground up.

      The boldfaced text in your first paragraph still holds true, at least I hope so :-)

      The disdain of mandatory Javascript may at least partially also stem from the knowledge that so called "text browsers" exist. I don't use lynx regularly, but just to prove it, I posted this comment with it. BTW a former colleague once said "if you can't get information from a web page with it, it doesn't contain any." I'm willing to concur still today.

        Yuuup Behold the millions of 5min videos used to read 5 lines of info interspersed with 5 min of jibber jabber
      It took me a while to figure out how to post a question. But I figured it out.

      I wonder if that's a common problem and if so how things could be changed to help. Every page has a link to PerlMonks FAQ which in turn links to I want to ask a question of the Perl Monks; where do I start?. The chatterbox is available on every page - did you try asking there? Did you try the search box? This site seems (to me) to be very well documented and certainly moreso than many others of a similar type but there's always room for improvement.

      Bold face is considered shouting in written communication. Please emphasize selectively and not whole paragraphs.
        Bold face is considered shouting
        Wasn't that ALL CAPS?
        Bold face is considered shouting in written communication.

        No, it is not, and to my knowledge has never been. Bold is used for emphasis. ALL CAPS is shouting.

        I don't think it's shouting. It's rather read the highlighted stuff in order to get an inlined management summary.

        "The boldfaced text in your first paragraph still holds true, at least I hope so :-)"

        Yes, it does.

        "Bold face is considered shouting…"

        No, I used bold letters just to make my text easier to read and stand out more. And I thought, if someone is in a hurry and just wants to read through quickly, then it's enough if they read the bold letters.

Re: Making Perl Monks a better place for newbies (and others)
by RyuMaou (Deacon) on Mar 19, 2009 at 19:58 UTC
    Wow, yeah, that was a great compilation of all, or at least most, of the issues. ++ indeed!

    I think "look and feel" are very subjective issues and, unless PM became unusable as a result of the redesign, I don't think I care much one way or the other about cosmetic changes.

    The "making PM friendlier to newbies" issue, though, I think is not that much of an issue. Sometimes, answers can be abrasive, sure, but mostly, I found this place no less friendly than anywhere else on the web. In fact, I think PM is less hostile than some places I've been! Granted, I try to do the basic leg-work upfront so when I ask a question I don't sound like idiot, but I learned to do that because of the harsh comments I read.
    I suppose if there was a section specifically for basic tutorials or people who specifically hadn't read a Perl book or any kind or something like that, it wouldn't be a bad idea. But, other than that, I honestly don't think it's all that necessary.

    So, there's my two cents, for all that's worth in the New Economy.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: monkdiscuss [id://751522]
Approved by jettero
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (3)
As of 2021-01-26 02:35 GMT
Find Nodes?
    Voting Booth?