A number of user-visible changes have been made lately, and I keep thinking there should be a way to announce and publicize such things, succinctly. No discussion, just headlines.

So I had this idea that a wiki node would serve the purpose quite well. It would be editable by the Cabal — all those who have the ability, in some form or another, to effect changes to the site. Only user-visible changes would be announced. For example, new shortcut types, refinements in site policy, relocation of important forms/inputs, new/deprecated user settings parameters, new/deprecated style elements (DOM classes), new/deprecated sections, etc., etc.

Announcements would be kept short, and could link to the PMD or other relevant node for further information.

Ideally, it would have an RSS feed as well.

(Update) A number of people have opined that PMD is the proper and best place for all announcements of site changes. I disagree, slightly, for this reason: PMD is not convenient for finding out, quickly and easily, what's new and different. On the one hand, there's way too much in PMD that isn't change announcements. There's discussion of ideas for future changes, often including extensive threads that wander off into other topics, devolve into arguments, etc. There's requests and complaints about the site from newbies who haven't quite got the hang of the place yet, and there's questions about how it works. On the other hand, the legitimate (post facto) announcements are scattered, one per node. The user who wants to see what's changed has to filter — visually — through all the PMD titles looking for likely candidates. To make matters worse, the titles of announcement nodes generally aren't headlines succinctly summarizing the changes; their authors like to get cutesy.

We're building the house of the future together.

Replies are listed 'Best First'.
Re: RFC: PerlMonks "What's New" Wiki
by dragonchild (Archbishop) on Apr 24, 2006 at 16:14 UTC
    What's the difference between this and providing a feature that allows only certain users (if any) to reply to a node? I think that the latter would be simpler to code up and would have the benefit of being useful in other situations.

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

      Well, that would work... but it has some disadvantages:

      1. It means a new node for every announcement, forever.
      2. It would (maybe) make the RSS feed harder to implement — or at least more costly, DB-wise, having to spider the thread.
      3. New items would appear at the bottom of the page, at least for those users who have their settings that way.
      4. It would be hard and/or messy to roll off older announcements as they become stale. Wiki nodes make this trivial.

      We're building the house of the future together.

      We already have various Wiki nodes that are used by site maintainers to record and discuss changes and ideas. Without having looked at how present Wikis are provided, I'd guess jdporter's idea would be pretty light weight to implement.


      DWIM is Perl's answer to Gödel
Re: RFC: PerlMonks "What's New" Wiki
by eric256 (Parson) on Apr 24, 2006 at 18:57 UTC

    How about just choosing a label like RFC for site updates and then prepending that to all site updates. Then we could add a simple link that does a super search for said prefix. I think that gets you everything you want. Old announcments could even be retitled fairly easily by the right people.

    And to get the ball rolling I vote for "Site Update:" though i'm perfectly willing to back a better choice. The important part is just to stick to it and implement an easy way to click a link and get a list of them. I wonder if this might be a nice way to add psuedo categories in the future. Like an RFC link that super searches for /^RFC:/

    P.S. this should also make an RSS feed trivial.


    ___________
    Eric Hodges

      Or we could do something that is user friendly.

      Update: Sorry, that was entirely too flip. Yes, your solution has a user friendliness element. However, I don't see that it is as close to an ideal solution as my proposal. (a) Announcements would still be scattered among the other PMDs. This isn't bad, but it isn't ideal (IMHO). (b) As PMDs, announcements could be replied to by monks. I think they shouldn't be susceptible to this kind of cluttering influence.* (c) All Monks will able to post a node that looks like an announcement. Yes, the janitors can go clean up such messes, but it would be better to prevent them in the first place... especially when an RSS feed is involved, and other caching issues.

      We're building the house of the future together.

      * It will happen. It's like a law of nature. For example, I posted XY Problem with the intention that it serve as a kind of unofficial reference document. I didn't want votes, and I didn't want replies. I got lots of both. For me this was an unpleasant learning experience. In hindsight, I probably should have posted it as a sitefaqlet; but I asked people's opinions on this first, and most were opposed.

        Feed back in the forms of votes, replies, etc, should always be welcome and not avoided. Your post was an excellent post and I don't think it lost any value by being voted for or replied to. In fact it probably gained a lot of influence for newbs when they see the replies and can tell that they arn't the only people to make this mistake and its not a horrible thing, just a fact of life. The point about anyone being able to post it is both good and bad, but we have a good set of janitors who do a good job keeping the site clean, and a good set of users who tend to follow the unspoken rules so I think that while its a flaw in theory, in practice it wont realy be an issue.

        My whole point was that some minor search mechanism can be linked to that will pull out just those posts so that while they would still be in PMD they wouldn't be buried in there amongst other stuff.

        I, for one, think that any announcment system should allow and encourage discussion. Discussion can help clarify why a change occured, how it can be used, and in many cases how it can be turned off (sense we have lots of people who like things the way they are and hate change. ;) )


        ___________
        Eric Hodges

        How is that not user friendly? If you have a link up top right labeled "Site Announcments" that automaticaly returns a page with the headlines of the recent announcments (a super search of some sort) and an RSS feed?

        I realy don't appreciate a response like that when you posted this here for discussion. If you have issues with my idea then please discuss them don't just dismiss them.


        ___________
        Eric Hodges
Re: RFC: PerlMonks "What's New" Wiki
by Scott7477 (Chaplain) on Apr 24, 2006 at 23:45 UTC
    I am 100% in favor of a "What's New" wiki structured along the lines suggested by jdporter. The statement that "PMD is not convenient for finding out, quickly and easily, what's new and different" is accurate as far as I am concerned.
Re: RFC: PerlMonks "What's New" Wiki
by jdporter (Paladin) on Apr 26, 2006 at 20:30 UTC

    It is done. Behold! I bring you Tidings of great joy.

    Let us offer sacrifices of thanksgiving to the gods.

    We're building the house of the future together.

      And now populated with its first entry. :)


      DWIM is Perl's answer to Gödel
Re: RFC: PerlMonks "What's New" Wiki
by shotgunefx (Parson) on Apr 25, 2006 at 10:38 UTC
    Having been somewhat sporadic in my visitations for quite awhile, I would have greatly appreciated something like this when I returned to a more regular schedule.

    Noticed so many updates and additions that I had no clue about.

    -Lee
    "To be civilized is to deny one's nature."
Re: RFC: PerlMonks "What's New" Wiki
by demerphq (Chancellor) on Apr 26, 2006 at 07:31 UTC

    I'm in favour of this idea.

    ---
    $world=~s/war/peace/g