Jump to content
Search

The new Ubuntu Wiki is live. Legacy content may be unavailable and page links may have changed. Read the announcement on Discourse.

Help talk:Editing

From Ubuntu Wiki
Latest comment: Yesterday at 13:00 by Shanecrowley in topic Removing pages

Captchas

Addition to Article

I would like to add to the article mentioning that users should be prepared to solve a captcha that requires access to a ubuntu commandline, particularly when posting links. This applies even to users who are logged in via launchpad, and to mobile users.

Broader discussion

I don't think it is great UX to surprise users like this, especially since many casual wiki users may be on their phones without easy access to a ubuntu commandline. This leads to a situation where a user may have typed a contribution, is stuck by the captcha, and then loses the contribution they made. From personal experience, this is frustrating and a negative impression of the new wiki

Additionally, the "help" link on the captcha is out-of-date, and cannot be edited or discussed by me at least. It mentions "blurry images" instead of the commandline challenge.

There should be a way to dial in the balance between spam protection and user experience.

Possible solutions:

  • Save a "draft" if a user is blocked by the captcha
  • Have a reputation system where logged-in users are exempted from the captcha
  • Ability to use more mobile-friendly captchas

Semitones (talk) 15:35, 28 September 2026 (UTC)Reply

Thanks for the feedback. We will put some thought into this.
The captcha is only shown in cases of suspicious activity by a user who is not autoconfirmed, which basically means a relatively new account with few edits.
The reason this is in place is because anyone can create an account and edit pages (this is a good thing), which means that anyone can also link externally to casino sites (or worse). The captcha is not supposed to be seen by most people doing regular edits. For legitimate users who trip it accidently, it's intended to be a temporary friction (they solve the captcha, soon become autocomfirmed after a few more edits, and never see it again).
You are correct that that friction is magnified on mobile currently, which is unfortunate.
There is a reputation system, in a sense, and it is has this user made edits over a reasonable period of time that have not raised alarm bells.
Whether there should be an alternative system in place is, while worth thinking about, a governance consideration with broad implications and some tricky implementation questions. When the wiki was in development, we explored some moderation systems, including those which, similar to your suggestion, held some edits in reserve; however, there were other thorny problems with those approaches. There are no perfect solutions to the problem of keeping a wiki open and reducing risk from attack while also maintaining a friction-free UX.
Some of the other points that you raise, however, should be fixable in the short term, including incorrect links and inaccurate descriptions. We have looked into more mobile-friendly captchas but there is a process for implementing them that could take longer.
One last thing that should be mentioned is that, in the grand scheme of things, external links should be kept to a minimum. First and foremost, the wiki should contain useful and interesting information, which doesn't always necessitate external links. Supporting information should mostly be provided by other wiki pages. There are exceptions, of course, and at this stage in its life the wiki does have some pages that link out a significant amount, perhaps excessively.
That is all to say, there are many things a new editor, who is not autocomfirmed, can do to improve a page, which don't require adding external links. We expect that the number of new editors who will both trip the captcha, despite making a valid edit, and also be on mobile and unable to solve it, will be small. We also hope that the incompatibility with the mobile experience will not remain for too long. Shanecrowley (talk) 22:58, 28 September 2026 (UTC)Reply

Removing pages

Essential for maintaining any documentation, but not even mentioned and no such option appears to be available.

Given the potentially significant impact of removing a page, this should involve a workflow which may involve approval. Wikipedia descibes using a suitable tag.

An example of a page which should be removed, rather than improved, is Install applications from Flatpak, for the reasons which I gave in my update to Managing software on Ubuntu. Note that I am not inviting discussion of the removal of that specific page here. Cainesaj (talk) 21:39, 29 September 2026 (UTC)Reply

Thanks. You are correct that there should be guidance on page removals, or tagging for page removals. Currently, delete rights require elevated privileges, to prevent abuse, which we think is reasonable. It's possible, just not by everyone because that would be difficult to manage.
A template for a "Page recommended for deletion" (or something like that) callout, which also adds a tracking category, can be created for this purpose. The editing guidelines can also be updated when it is available. No objections to any of that.
As for the Flatpak guidelines, if you could outline what is unhelpful or misleading about that page in that page's discussion it could be useful, because it is difficult to glean what you mean from the update alone.
My only comment there is that the Managing software page is obviously an overview encompassing many technologies, which is a nice thing to have on this wiki. The (external) Ubuntu docs will obviously have a lot of detail on things like Snaps, but likely not Flatpaks, and some others. So let's consider if there is scope for a standalone page on Flatpaks, if, for example, the managing software page was to become unwieldy and needed to link out to dedicated pages, which might also be easier for users of a specific type of software to search. It doesn't have to be deleted necessarily, but maybe it needs improvements to better justify its existence, or perhaps it should cross-link to the software management overview. Shanecrowley (talk) 23:48, 29 September 2026 (UTC)Reply
Thank you for the considered response to the absence of page removal information. I look forward to seeing how it's implimented.
Since I agree with each of your points concerning the specific page, the discussion of which I tried to discourage here, I'll address your question there as you suggested. Ajcxz0 (talk) 19:23, 30 September 2026 (UTC)Reply
@Ajcxz0 @Cainesaj
I have added a section on deleting pages here: Help:Editing#Deleting_pages.
The implementation is not as sophisticated as Wikipedia's right now, but it doesn't need to be. That may change as the wiki grows and it will be something the admins discuss. Shanecrowley (talk) 13:00, 13 October 2026 (UTC)Reply