I think the comments can be useful, but there are a few comments that are not. Perhaps martin's suggestion of being able to bury/down vote the silly/wrong comments, could be a solution to maintaining a comment system and being able to filter out the not so helpful comments. I don't think removing the comments entirely is a good solution though.
The suggestion about adding comments to the API is an interesting one, and perhaps something I will try to look into when I get a chance. -Mark On Feb 17, 8:54 am, Martin Westin <[email protected]> wrote: > This has a lot to do with: What is a comment? or more likely: What > should a comment be about? > > There is: > Desire to add, modify or remove content - Editing. Which we have in a > moderated form. > Desire to offer usage examples and tricks - Comments (as php.net for > example) <-- my interpretation of a comment > Desire to report on bugs and problems regarding the book application. > Cakebook tracking system > Desire to have questions answered. Google group > Bitching and moaning. /dev/null > ...among others... > > We have forums for most of these things. The tricks and examples bit > is also something the bakery and this group has plenty of already. > > I could see the comments go away if they were "replaced" by some form > of public edits. It is a long and winding path from seeing a "hole" in > a chapter to seeing an edit published. I do think that something with > a lesser barrier has a purpose. Sort of how Tomtom do map updates for > their GPS's these days. You can submit a "new" change in the roads and > anyone can choose to download "official" maps of more experimental > maps that have not been fully verified yet. > > I would personally want to be able to se all suggested edits even > rejected ones. This is because I know some edits have been rejected on > the grounds of being too detailed and complicated for beginners (i.e. > explaining every small detail and every eventuality) and that is > sometimes exactly the kind of information I want. > > As a post on the group from yesterday (I think it was) suggested. > Comments for the API might actually be more useful than in the manual. > I haven't checked how problematic that would be to implement, though. > > OT much? > My 2¢ in short: Comments can go if unofficial edits takes it's > place :) > > /Martin > > On Feb 17, 12:22 pm, Adam Royle <[email protected]> wrote: > > > I think the comments should stay, but improve the functionality to make > > them more useful/constructive. > > > Develop a upvote/downvote system for comments. This should eliminate > > stupid comments from wasting people's time, and the popular comments > > should indicate what parts of the manual could be improved. The good > > comments could even be visible on the page by default instead of hidden. > > > Although I understand your suggestion that people should just edit the > > manual to include what they're suggesting, some people: > > > a) might not want to impose their code on others (beginners might be > > unsure what is the best way to do something and don't want to mislead > > others) > > b) might be too lazy to contribute something of value, due to language > > barriers or lack of ability to write meaningful prose > > > I'm sure we all agree that reading through the user comments in the PHP > > manual is a great source of WTF fodder, but there are some serious gems > > in there that have saved my butt a ton of times. > > > Cheers, > > Adam > > > AD7six wrote: > > > Hi All, > > > > Before doing anything rash I'd like to ask the community: Is the > > > possibility to add comments to the book doing more harm than good? > > > Should the possibility to add comments be removed? > > > > The main reason for asking is that, although things have improved > > > lately, many comments should have been submitted as corrections or > > > additions to the contents. Some examples to illustrate (the goal is > > > examples, not finger pointing/witch hunting): > > > > Should have been a ticket: > > >http://book.cakephp.org/comments/3#comment_562 > > > > Should have been an edit: > > >http://book.cakephp.org/comments/index/162/Localizing-Your-Applicatio... > > > > Should maybe have been a post here: > > >http://book.cakephp.org/comments/index/162/Localizing-Your-Applicatio... > > > > Trying to talk to Admins: > > >http://book.cakephp.org/comments/29#comment_536 > > > > Talking to yourself: > > >http://book.cakephp.org/comments/566#comment_462 > > > > Should not have started reading at the end of the manual: > > >http://book.cakephp.org/comments/index/449 > > > > Misleading: > > >http://book.cakephp.org/comments/index/449#comment_639 > > > > Flat out wrong: > > >http://book.cakephp.org/comments/index/449#comment_574 > > > > Vampy: > > >http://book.cakephp.org/comments/95#comment_529 > > > > Etc. > > > > Probably the biggest problem with adding comments (and users who speak > > > more than one language will have already noticed this) is: if it's > > > actually useful - the translations have absolutely not indication of > > > whatever nugget of information unless it is submitted as an edit to > > > the contents. > > > > If you're familiar with the book's source (http://thechaw.com/ > > > cakebook) you'll know that there are some things coming to help guide > > > users to channel their efforts to be more effective, what else/more > > > should be done to further improve things in this regard? > > > > On topic suggestions on a postcard please, > > > > AD > > > PS. No how-the-book-should-work wishlist hijacking please (RFC/ > > > enhancement tickets as appropriatehttp://thechaw.com/cakebook/tickets > > > OR fork, implement your functionality and ask for it to be integrated) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
