Why were my edit suggestions of fixing URL rejected?

Question

I recently suggested a very small edit to a post fixing outdated URLs which were rejected 2 times with the same reason.

The rejection notice states:

Rejected 3 hours ago:

Kevin Bowen reviewed this 3 hours ago: Reject
This edit does not make the post even a little bit easier to read, easier to find, more accurate or more accessible. Changes are either completely superfluous or actively harm readability.

Eliah Kagan reviewed this 4 hours ago: Reject
This edit does not make the post even a little bit easier to read, easier to find, more accurate or more accessible. Changes are either completely superfluous or actively harm readability.

The edit was changing the following two URLs to working URLs.

# URLs in original post
wget http://security.debian.org/debian-security/pool/updates/main/j/jasper/libjasper1_1.900.1-13+deb7u6_amd64.deb
wget http://security.debian.org/debian-security/pool/updates/main/j/jasper/libjasper-dev_1.900.1-13+deb7u6_amd64.deb

# Suggested changes
wget https://debian-security.sipwise.com/debian-security/pool/main/j/jasper/libjasper1_1.900.1-13+deb7u6_amd64.deb
wget https://debian-security.sipwise.com/debian-security/pool/main/j/jasper/libjasper-dev_1.900.1-13+deb7u6_amd64.deb

I'd like the URLs fixed and my stats to not be damaged via this. Do I just re-edit, what is the proper course of action?

Answer 1

As you know, I am one of the reviewers who rejected (both of) your attempts to apply this edit.

I think it is far from obvious that the specific change made here is correct or even safe. There are two issues:

1. It's not clear that changing the mirror is better than recommending the newer version that is available in the same place. Even in the post's current broken state, users who try to follow its directions are likely to find and (attempt to) use these newer packages. This might actually be better than using the old ones.
2. It's not clear why the mirror you're recommending should be trusted.

Both of these concerns could be addressed by providing more details in the immediately surrounding context, such as in the edit summary.

---

When a specific version of a package disappears from an official repository, the reason is often that it is considered obsolete. This can happen when it has been superseded by a newer version that provides security or stability fixes. When a newer version has appeared in the same directory as the older version, and the older version has been removed, this does not ensure that the newer version should be used, but it is a sign that the newer version should be considered.

The typical way to fix a URL that is broken because it links to something obsolete, when there is a similar non-obsolete version available officially and in the same place, is to replace it with a link to a version that is not obsolete. In this case, that would entail changing the filenames to libjasper1_1.900.1-debian1-2.4+deb8u6_amd64.deb and libjasper-dev_1.900.1-debian1-2.4+deb8u6_amd64.deb.

But one should be careful about that, too. It may be that this approach is unsuitable and that the change you are trying to make is preferable. For example, perhaps the newer version is less likely to work on the Ubuntu release the answer is written for. Or perhaps there is something specific to the problem being solved--the software it is being installed as a dependency for--that would cause breakage.

If, in view of this, you have good reason to believe that the specific change you are making is appropriate, then you could resubmit the edit with the necessary information so that reviewers can evaluate it. Usually this can fit into the edit summary you write. Sometimes it makes sense to comment on the post. Occasionally--when the information is clearly relevant to people following the directions in the post--even an explanation in the body of the edit is appropriate.

Suggested edits often require some research effort from reviewers, and this does not always justify rejecting them. I think it is an open question as to how much of the burden of research can reasonably be foisted onto reviewers. However, this situation goes beyond merely requiring reviewers to verify that an objective factual claim is correct. Your (now two) edits don't provide any justification for solving the problem the way they do, and they effectively leave it to reviewers to do one of the following:

• creatively come up with the missing justification, hope it's along the lines of what you were thinking, and investigate it
• carelessly approve the review
• reject the review

---

There is also the matter of the specific mirror chosen. When fixing a broken link to a website that is provided for further reading, just about any archived version will do. But when it comes to sites that provide software for users to download and install, it should always be clear that the site is a safe choice.

When one installs packages with APT from a configured repository, APT checks their hashes (unless told not to do so). The hashes themselves are digitally signed.

But that does not appear to apply here. The directions in the answer recommend manually downloading .deb files and installing them with dpkg -i. Therefore, it is of utmost importance that the server the post recommends be reasonably trustworthy.

If you resubmit this or a similar edit, then I recommend ensuring that enough information is available--in the edit summary or immediately surrounding context--to address that concern as well. Ordinarily, for Debian mirrors, it would be sufficient to link to https://www.debian.org/mirror/list and mention it is listed there. However, the mirror you are recommending is not listed there.

Answer 2

I see that you flagged your post for moderator attention and then pointed here.

All the points made by Eliah Kagan in their answer to this discussion post are valid and are 100% accurate. As I stated in comments on the other answer in response to you:

In the world of Debian, you should only be recommending on a public Q/A site mirrors that are listed on the Debian mirror sites page. NOT unvetted third-party ones. This is more for the safety of other users than not. You're free to suggest in comments that they use a specific mirror, but because we can't vet the mirror nor can Debian, the mirror is untrusted and I'd even swoop in and make a nice big warning comment about "Untrusted Mirrors". The rejection of your edit suggestion was valid, and I would've rejected it myself as a moderator as well if I had seen it.

(this applies to the Ubuntu world as well - we only suggest the public mirrors that're part of the round-robins as well, even country regional mirror lists - mostly because those are more trusted.)

While you state that "this isn't an authoritative website" we still strive to be as 'safe' as we can.

Further, as another example, if I changed the mirror in that URL to ubuntu.thomas-ward-consulting.llc (which is actually a mirror synced directly from archive.ubuntu.com and maintained through my LLC I personally own) or a similarly owned URL that would be a Debian mirror, that would be a similar example of an "unvetted" and "unsafe" Mirror to recommend be used for syncing. It would also 100% be an example of 'spam' and 'advertising' because I'm driving business and network activity to my own sites.

And even if I disclose I run the mirror, there's no way to vet that the mirror is identical to the Ubuntu repositories or Debian repositories and that I haven't done something egregious or malicious with the data on the repositories. So it would have been rejected if I had tried the same (and as a moderator, the community would end up outcrying my edit actions here in Meta and I'd be publicly shamed forever - that said, this is why I don't share links to my sites or resources unless it's a valid resource such as a blog post I've summarized in an answer but am pointing people to as source material I wrote).

For these reasons as stated, we (that is to say, the community at large) rejected your edits. If you attempt to make the same edit again, it will get rejected by the community again.

To that end, when attempting to fix 'broken' URLs for Debian Mirrors, Ubuntu Mirrors, etc. please only use the official lists of Mirrors that are known to be 'safe' as vetted by the Debian and/or Ubuntu teams.

---

Also:

I'd like the URLs fixed and my stats to not be damaged via this.

I'm not entirely sure what you mean by "stats to not be damaged" here - and even then, 'stats' are not a useful indicator on their own of 'value' of activity. You could have a hundred answer posts you've made and none of them downvoted and all of them upvoted but none of them accepted as answers. That's just a 'statistic' that has no real bearing on the quality of your posts/activity.