Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??
I mentioned this in another thread, and Anonymous Monk kindly suggested I float it in its own thread - so here we go.

The problem at hand re anonymous users is that some people really really love Anonymous Monk, and others really really don't. There are certainly folks who are very vocal about this both ways and who continue to be; the consensus has always been either anonymous posting must completely stop forever and the Anonymous Monk be eliminated, or anonymous posting must be left as it is because it is too difficult to do anything about it.

I'd like to propose a possibility that might let both sides of this discussion have what they want - it it obvious that there is at least some dissatisfaction with anonymous posting as-is, and it's also obvious that we're not going to eliminate a feature which is very popular with many.

(Those who understand the internals of the Perlmonks engine, bear with me; I've not seen the code, so I do not yet know if this is feasible. If I'm incorrect, let's talk it over and see if the concept is something we can work with, even if my specific implementation guesses are not.)

Requirements:

  1. We keep the Anonymous Monk. This is, from much reading here, not negotiable.
  2. There are, from time to time, personality conflicts among the members of this site. This is simply a fact.
  3. At times, some people may not want to see postings from others, either selectively, or at all.
  4. Any proposed solution must not alter the current functionality's default operation.
  5. Any suggestion must be as small as possible a change.
This seems like a difficult set of criteria to meet without altering the most basic characteristics of the users - but let's look at this from a different angle. What if we made "allow anonymous users to respond" to be a characteristic of a node instead?

We'd default this characteristic to be on unless turned off. If turned off, all child nodes of this node would inherit the characteristic (whether by data inheritance or plain old copying is an implementation detail - suffice it to say that the characteristic would be added to each node, and only the first node in a new thread would have the option of setting this characteristic - for simplicity, if you started out open, you don't get to "take it back"). All child nodes would retain the parent's characteristic, and would not be allowed to alter it. However, if node characteristics are truly inheritable from a root-of-thread node, then "taking it back" is possible (what is my root node's current "allow anonymous" setting?), and a nice thing to permit. I do not think nodes should be pruned if this setting is changed; that adds too much complication.

Alternatively, each top node could have a pointer to the originator's "block list". Checking a "no anonymous replies" checkbox in your home node adds the Anonymous Monk to this list; a secondary input field/page in the user's home node settings would allow them to add other ids to the block list (probably stored as home node IDs). Each new thread would copy/inherit the block list from the user to the root node - probably copy, as we don't want the changes to propagate across large swaths of the database if someone posts a lot then alters their block list. Each subsequent child node would continue to receive this block list.

Users who did not want to block the anonymous monk would leave the box unchecked (and if the block list exists, would have an empty block list); this allows them to use Perlmonks in the style to which they are accustomed.

Users who want to block other monks (whoever this might be) would add them to their block list (or check the box), and they would no longer have to see posts from those monks. Blocked monks would receive a polite "monk prefers not to see your posts, sorry" message when trying to post to a node/thread on which they are blocked.

Considerations should not be blockable; I'm on the fence about votes. Needs discussion to tease out the positives and negatives here.

Let's please not simply say declare it impossible; let's think about it and see if we can partly do it if the whole idea doesn't work. If there are architectural issues, let's look at them and see if there are any further ideas that might let us move forward in a different way with the same kind of function.

It just comes down to each monk being allowed to control what they wish to read, which is a reasonable goal. Let's see if we can find a way to meet it. I am more than happy to do (and capable of doing) work to make this happen.


In reply to Having our anonymous cake and eating it too by pemungkah

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 admiring the Monastery: (5)
As of 2024-04-25 11:18 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found