Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Codidact Meta!

Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.

Comments on Regular deletion (roomba) of content unlikely to ever be useful

Parent

Regular deletion (roomba) of content unlikely to ever be useful

+9
−0

I noticed that questions exist on this network and are accessible that are unlikely to ever be very helpful, for example because they were marked as completely off-topic.

Examples

The content license does not mean that there is an obligation to keep the content here and removing such content would increase the signal to noise ratio. I don't see much sense in keeping this content. We could therefore permanently remove it from the system.

But there are also questions that have a very low score (typically they are not very high quality with missing information) and often also no answers but aren't closed. With edits and answers they could potentially be converted to something useful, but that may not be very likely. The decision to keep or remove such content might be a bit more difficult.

However, cleaning up more regularly might also increase the appeal of the front pages of the individual sites (see recent discussion).

Should we regularly remove content we deem to be not useful at all?

If yes, what should be the criteria for that (close status, score, number of answers, life time)? Should it be done automatically (automatic cleaning robots) or rather manually (at least for now)? Where should the criteria for that be decided (for each community individually or network-wide)?

Searched for it on Meta but couldn't find anything for "automatic deletion".

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

0 comment threads

Post
+1
−1

I personally like the way you are contributing(not for voting, re-editing posts and some other stuffs).. You may have seen somewhere that, only 2 people are working as coder in the Codidact organization. So it's taking huge time to build up things. I believe Ruby on rails is little bit harder that's why most of peoples can't contribute to code. I was also a contributor. All the things I understood after working on the organization that is, "maybe I can't understand how one page is linked with another one in ruby-on-rails". One of my friend, also said that, "after QPixel he hates ruby-on-rails" (not sure if I phrased correctly). ~ I said it cause you were looking for automatic deletion.

Everyone thinks deleting poor questions may help to speed up the growth of the community. But a staff (it's more than 3 months so I don't remember if that was staff or someone else) said, "removing all imported contents will be helpful cause some of our communities are getting down for copyright-infringement but what can we do if someone had edited and done some effort on that post?"

We could therefore permanently remove it from the system.

Removing something from database permanently is never helpful. Cause there is a report in Writing which had happened for "data error". We can remove thing softly- the way we are doing now.

Usually, all the bad posts are posting by some specific users. When we say something by mentioning them, then they don't reply to our messages. I believe we should have discussion with them. It's OK not to know things but deleting their contents without informing them isn't really a good idea. So I always suggest to discuss with those persons. I sometimes worry why they don't want to listen to us.

I had asked in Discord once when do a moderator remove the participate and participate everywhere ability, no one replied. But if we revoke those abilities then they might come to us to discuss (I don't know even I don't think anyone will listen to me but all the things I say that is I don't care). Some may say to suspend them, I said in the answer why suspending is never helpful.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

2 comment threads

Workload of devs is irrelevant (4 comments)
Revoking or suspending abilities (1 comment)
Workload of devs is irrelevant
Lundin‭ wrote about 3 years ago

The workload of the devs is irrelevant for suggesting and discussing features - people shouldn't hold back on discussions. The more something is discussed, the more mature the feature suggestion gets, the easier it will get to implement - particularly if many the "ifs and buts" use-cases are considered early on, at the non-technical level. Which features that actually do get implemented and the priority order is a different story - everyone is a volunteer, so there will always be a bias towards feature suggestions that a certain dev find fun, interesting or useful. Ideally our devs should enjoy themselves while implementing something, as it is something they do on their free time as a hobby.

Canina‭ wrote about 3 years ago

I agree that developer workload should not be a factor in suggesting features. Also, this isn't even an actual feature suggestion, it's a discussion along the lines of the boldfaced "should we do this?". Developer workload absolutely can be a factor (even a large factor) in deciding which features actually do get implemented, but that too has to at some level be weighed against the proposed feature's usefulness. Even an extremely complex feature can be worthwhile to implement if it provides great value, whereas an extremely simple feature might still be decided against if it doesn't provide any value (or even provides negative value, as the case can be). Discussing what would be the value of some given functionality is an integral part of deciding if implementing that functionality is worthwhile.

deleted user wrote about 3 years ago · edited about 3 years ago

I know It's irrelevant, but he wanted feature like automatic deletion. We want to have that also but we can't work soo fast for lackness of programmers. That was the main reason of saying that. And I mention it but didn’t clarify cause I always believe that seniors can understand "things" easily.

And if they "chose" easier language (like Node.JS, Django), than lot of people might help

Canina‭ wrote about 3 years ago · edited about 3 years ago

Especially for an open source project, the beauty of having a discussion out in the open about whether or not some particular kind of functionality should exist (or even a more detailed feature request) is that if someone comes across this half a year, a year, two years from now and it isn't yet implemented, and said person thinks it's a neat idea that they would be willing to put some time and effort into, they can do it. However, if the publicly visible consensus is "that's a really bad idea and here are a dozen reasons why that's so", that person will probably realize that if they want to contribute code to Codidact/QPixel, there are things that are probably a better idea to work on and would be more likely to be positively received by the core developers even if they themselves think it would be a cool thing to add.

(All that regardless of the current developer workload and regardless of the specifics of the idea in question.)

deleted user