<p>First of all, thank you Andy for picking this up!</p>
<p>I agree that the current database structure sounds heavily engineered, and would indeed tend to go with just one table like you've suggested. I would add one flag (approved/removed/spam?) if the reports have been acted upon, and one flag to objects to ignore further reports.</p>
<p>Showing the number of reports is maybe not desired. If the reports are a black box, it encourages duplicate reports, which make it easier to prioritise moderator actions, or even <a href="https://www.reddit.com/r/AutoModerator/comments/41xzms/possible_to_have_automoderator_remove_posts_that/">remove objects automatically</a>, which I do on the few subreddits I moderate on reddit, based on a few criteria like user age or posting history.</p>
<p>Reports that have been acted upon should not be deleted. They are useful to respond to user complaints, and make interesting statistics.</p>
<p>Could the report interface be a modal dialog to preserve user flow? What's the interface like from the moderators' perspective?</p>
<p>The comment should not be mandatory. Spam, for example, requires no further comment.</p>
<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/openstreetmap/openstreetmap-website/pull/1576#issuecomment-313418715">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABWnLbi-L1V5uJrIseMorATGvNqZ_J0vks5sLPO1gaJpZM4OOfLC">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ABWnLaaw2ns-K63w7wygmDSyXnTlGKUaks5sLPO1gaJpZM4OOfLC.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
<link itemprop="url" href="https://github.com/openstreetmap/openstreetmap-website/pull/1576#issuecomment-313418715"></link>
<meta itemprop="name" content="View Pull Request"></meta>
</div>
<meta itemprop="description" content="View this Pull Request on GitHub"></meta>
</div>
<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/openstreetmap/openstreetmap-website","title":"openstreetmap/openstreetmap-website","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/openstreetmap/openstreetmap-website"}},"updates":{"snippets":[{"icon":"PERSON","message":"@grischard in #1576: First of all, thank you Andy for picking this up!\r\n\r\nI agree that the current database structure sounds heavily engineered, and would indeed tend to go with just one table like you've suggested. I would add one flag (approved/removed/spam?) if the reports have been acted upon, and one flag to objects to ignore further reports.\r\n\r\nShowing the number of reports is maybe not desired. If the reports are a black box, it encourages duplicate reports, which make it easier to prioritise moderator actions, or even [remove objects automatically](https://www.reddit.com/r/AutoModerator/comments/41xzms/possible_to_have_automoderator_remove_posts_that/), which I do on the few subreddits I moderate on reddit, based on a few criteria like user age or posting history.\r\n\r\nReports that have been acted upon should not be deleted. They are useful to respond to user complaints, and make interesting statistics.\r\n\r\nCould the report interface be a modal dialog to preserve user flow? What's the interface like from the moderators' perspective?\r\n\r\nThe comment should not be mandatory. Spam, for example, requires no further comment."}],"action":{"name":"View Pull Request","url":"https://github.com/openstreetmap/openstreetmap-website/pull/1576#issuecomment-313418715"}}}</script>