david-a-wheeler
commented
6 years ago Here is a more detailed proposal:
Create a new SQL table called "feedback" with the following fields:
- id: Primary key for each feedback value (as normal)
- created_at, updated_at: Time the comment was created/updated (as normal)
- project_id: NOT NULL, Id of project it comments on.
- user_id: NOT NULL, Id of user making the comment.
- comment: String, to be interpreted as markdown text that is a comment by user_id about project_id. As with all markdown processing (as implemented in ProjectsHelper), the renderer will have filter_html: true and rel: 'nofollow', so any hypertext links will not improve any site's Google ranking (eliminating any reason for unscrupulous SEO consultants to add comments).
- hide: Boolean, default F, NOT NULL. If T, this comment is not shown on the public site
- reviewed: Boolean, default F, NOT NULL. If T, an admin has reviewed the comment.
- reviewed_at: DateTime, default null. Set to the last time an admin reviewed the comment.
Proposed access control: Only logged-in users can add feedback about a project. Only the owner of the feedback or an admin can hide or delete a comment (note that project owners cannot control comments about the project entry). Only an admin can mark a comment as reviewed or not.
User interface:
- A logged-in user, on seeing a project that they CANNOT edit, will see a new "Feedback" option (instead of "Edit"). Should it be called "Comment" instead? On selecting that, they get a form that lets them fill in a comment; the form provides hints on how to insert useful hypertext links to specific project issues. The form has a "submit" button that, once pressed, adds the comment. (Should there be a preview mechanism?)
- Anyone who views a project can see, at the bottom, a list of all unhidden comments about the project entry. There will be a "delete" and "hide" button on each feedback entry that is owned by the current user; every feedback entry will have a "delete", "hide", and "reviewed" button if the viewer is an admin. Selecting those buttons, where access control permits it, changes the feedback record.
- Admins will have a separate admin-only page that can show all comments or all unreviewed comments in the datetime order, along with links to the project commented on.
Debatable options:
- If a user or project is deleted, should we delete the related feedback? The simple answer is "yes", so I think we should start with that; then we don't have to deal with missing links.
- Should users be allowed to edit a comment, once made? The easy answer is "no", so I suggest we start with that. We could change it later to edit for only a period of time, like Hacker News, or just allow arbitrary edits like GitHub.
- A non-admin user should not be able to add feedback to a project that user can edit. That's debatable since maybe a group would want a way to discuss the project entry, but members of a project probably already have their own way of doing that and we aren't trying to supplant that.
- "Hiding" and "deleting" aren't much different; maybe we should drop hiding, at least at first, and add it back later if it turns out to be needed.
This is a first cut. Suggestions welcome.
dankohn
kestewart
Some projects may incorrectly claim to meet requirements they don't, or worse, falsify an entire badge entry. This is one of the problems with self-reporting. We already require badge entry information to be public and automatically check some values, which counters the problem in some cases, but we're starting to see cases where people seem to be falsifying information and/or entire badge entries.
The obvious next step is to support publicly-visible comments/feedback by others on a project badge entry. This would allow others to comment on a project entry. I intend to follow up this comment with a more detailed proposal, but hopefully this explains the motivation and basic idea.