Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re: Multiple scratchpads - one public, one private

by Shinwa (Beadle)
on Jun 08, 2004 at 21:47 UTC ( [id://362570]=note: print w/replies, xml ) Need Help??


in reply to Multiple scratchpads - one public, one private

What I think would be interesting would be group wikis (or group scratchpads)

This is a good idea for the most part, as I know many users would like to engage in group projects without as much hassle.

As far as only allowing higher monks to use them, that is up to the monks. I would personally like to see a system where perhaps someone of a ranking could create a group scratchpad, and then be able to invite others to write upon it. That way only those associated with the project may contribute, as well, you would save space by not having to worry about creating pads for each and every user.

...most folks that would actually take advantage of the feature would be abbot or above...

This I don't think should be assumed. I myself am still the rank of initiate, but would readily use such a feature as a group scratch pad. I've actually already discussed group projects with other monks of various rankings....

---------------------------------------------
Shinwa : Did that penguin just meow at me?
Snuggy : What hunny?
Shinwa : nuffin' luff...
  • Comment on Re: Multiple scratchpads - one public, one private

Replies are listed 'Best First'.
Re^2: Multiple scratchpads - one public, one private
by ysth (Canon) on Jun 09, 2004 at 00:20 UTC
    The problem with a public scratch pad is that it is public, and anyone can just come along and wipe it. If that's ok with you, feel free to use Whats a wiki?. Less interesting is the publicly readable but writable only by gods Cloud nine.

    <injoke> Of course, we all know that if there were such a thing that were accessible only to, say, acolytes and above and writable only by abbots and above, it would be a productive place where much collaborative work could be done. </injoke>

Re^2: Multiple scratchpads - one public, one private (personal wiki)
by tye (Sage) on Jun 09, 2004 at 17:37 UTC

    I think we should change the wiki edit page to only allow janitors and owners (not writers) to be able to change wiki titles. We need to fix the canUpdateNode() and canReadNode() to special-case wikis so we can use them several places (and so regular displaytype=edit can work on wikis). Once that is done, I think we could do the following...

    At ysth's suggestion, I could go for allowing members of a certain level to create a *single* wiki that they could change the title of and set the permissions on (you are limited to setting a minimum level or picking an existing group -- though if people start making requests for new groups to be added, I'm going to delete their wikis). The node=tye;type=user;displaytype=xml would report the node ID of my wiki if I had one like it will soon do for scratchpads. Super search would allow you to search wiki's by content, title, owner, just like it does for other nodes (we'll need to have it post-process the list and not list nodes that you don't have access to read, a simple change).

    And, of course, gods can create wikis with a specific title and permissions if given a good reason to.

    We'd want a superdoc that lists wikis sorted most-recently-updated first (create a bookmark that feeds it a specific list of wiki IDs if you only want to check for updates to certain wikis).

    If your wiki gets wiped out (or otherwise ruined), then you can use "edit history" to see who changed it when and how and cut'n'paste removed parts back into existance (which should be a good reason for people to not bother wiping wikis). This "history" link needs to become public (in the "title chooser", where "print" and "xml" links are, preferably only if there are history records to see), not just in the janitors' nodelet. But we need to limit who can see the contents of edit records to not include those who can't see the node that was editted and to limit it somewhat for fully public nodes1.

    You wouldn't be allowed to delete your wiki, but you could empty it and set the permissions so noone else can edit it. This is just so wiki node IDs don't scroll up and up when people can't decide whether they want a wiki or not.

    The space required for wiki edit history could become rather huge, which is one reason why only one wiki per person and only after you reach a certain level. pmdev implementing "preview" for wikis could help a lot with that. A purge process will eventually be needed either way (and I believe in lots of history, so I wouldn't purge records less than 1 year old).

    If your wiki becomes a great success, then it could be adopted by the gods (which would make its title and permissions somewhat set in stone) so that you could create a new personal wiki.

    - tye        

    1 Some appear to not want the public to be able to see edit history of nodes (every edit to a wiki is recorded; for other node types, only edits done by janitors are recorded). I guess one point is to prevent robots from finding e-mail addresses that were removed when someone realized the spam risk. I'm not sure we should prevent the public from seeing edit history, but perhaps just restricting it the registered users would be enough? That prevents anonymous monks from seeing how a node change which they certainly may have valid reason to do, but I don't feel too sorry for them if they have to register for that access even if they feel that they never want to post via that account.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://362570]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others admiring the Monastery: (2)
As of 2024-04-20 04:11 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found