Is it possible for the developers to disable SuggestedEdits on Commons images for now? It seems there are plenty of people from the Commons community dissatisfied with the unconstructive edits made by the tool. See c:Commons:Village pump#Very large number of troubling edits with SuggestedEdits. Thanks
Return to "Wikimedia Apps/Team/Android/AppEditorTasks" page.
Reply to "Turning off SuggestedEdits on Commons"
Reply to "Bad typography in descriptions"
Reply to "Update the Image tags section for "Suggested edits" help page"
Reply to "Suggested Edits on Wikidata articles that already have descriptions"
Turning off SuggestedEdits on Commons
@Pandakekok9 Just wanted to acknowledge that this has been seen, and that we aren't ignoring it – just that we've had the holidays and are having changes in the team, which means that it takes longer time to reply.
OK, I just had a brief meeting about this, and we're scheduling more time in the team in the coming days to look at the conversation and what we can do. We have a new product manager coming in, @JTanner (WMF), and this will be one of her main priorities now. You should expect to hear more from us next week.
Taking a closer look at this will be one of the main goals of the Android team in the coming months.
Thank you for the updates @Johan (WMF)!
Bad typography in descriptions
I see a lot of bad description added with Suggestededit. Especially in typography, description in French starting with an uppercase letter (which should rarely happens) or ending with a punctuation (which should almost never happened). Couldn't these mistakes be removed?
Hi, thanks. We're working on quality controls and aware they're not as good as we wanted them to be. I'll bring up this specific issue.
Thanks, it would be both great and easy to fix this problem.
I agree: I often see descriptions wrongly starting with an uppercase letter or ending with punctuation. Is there any update about these two problems? Thanks!
The suggestion are not really bad (I changed the title), the content itself is globally good enough, it's only the typography (and only of the first and last character).
Here the solution seems pretty simple and could be something like:
- if the suggestion ends with a punctuation (or start with an uppercase), remove the punctuation, except for a whitelist of the few exception where the punctuation is ok (there is almost no exception for punctuation, maybe a lot and tricky ones for uppercase...).
Capitalisation sounds really tricky. For example:
"Poet and playwright from Quebec"
"Quebecois poet and playwright"
One of these shouldn't be capitalised, one of them can take the capital letter. And then it would vary from language to language – unless I'm mistaken, neither of these should capitalised in French, nor should they in Swedish, but that just makes it more difficult since we have so many languages.
Yes it can tricky. There is even more tricky cases like "church of England" (for a place) and "church of England" (for an organisation).
That said, in most languages and in the majority of cases, it's ore probable to start with a lowercase than with an uppercase. If we go for a simple rule: "all in lowercase" is better than "all in uppercase" but of course there is a lot of exception (German is almost always uppercase for instance).
A better but more complex rule could be something like "look at the value of P31 and if the first word is the same as the label of the value of P31 then follow this casing". This is basically the query I do everyday for correcting labels and description of churches and Churches ;)
My reply in https://phabricator.wikimedia.org/T255985 is probably relevant here too:
These are our current plans to address the specific problem of capital letters and punctuation in Wikidata descriptions:
- Adding another step to suggested edits onboarding in the app specifically about this
- A warning when the user starts the sentence with a capital letter – this might not be desired behaviour, sure you want to continue?
- A warning when the user ends the sentence with punctuation – this might not be desired behaviour, sure you want to continue?
We're also looking into long-term solutions for more general issues. One major thing we have yet to solve is re-working detection of bad edits (this is currently based on undoing and reverting of the editors edits, but that proved ineffective). We're also doing some other investigations to see how we can ease the burden of patrolling.
Update the Image tags section for "Suggested edits" help page
I see that the app doesn't show suggested image tags anymore. I believe it would be helpful to also update the Suggested edits#Image tags section accordingly for the meantime as it is directly linked from the "Tag images" screen of the app.
Thanks for the reminder!
Looks like the content of that section has been updated to reflect the status-quo which is nice. But the images in that section are still misleading. The first one and the last one, to be specific. It would be nice if they could be updated too.
I would've done that myself but thought it would be better to leave a suggestion to ensure the screenshots are consistent. :)
Thanks @Kaartic - we'll get the screenshots updated!
Discussion about the push notifications feature being developed in the app.
I just had a couple of doubts related Push notifications which I thought of asking.
Relation with AppEditorTasks
This wiki page is about AppEditorTasks which I suppose is the code name for the "Suggested edits" feature. I find it interesting to see information about push notification in this page as I don't see how push notifications are related to suggested edits. Could someone clarify this for me?
Were push notifications tested in alpha app?
Apologies before hand for asking a doubt about the alpha app. I just couldn't control the curiosity :)
A few days ago, I remember getting notifications from the Wikipedia alpha app for a thank/talk page edit. Note that I distinctly remember this as this is the first time I've ever got notifications from the Wikipedia app (yeah, I don't get a lot of wiki notifications). I don't remember exactly whether I had the "Poll notifications" preference on/off at that time. I don't remember turning it on. So, I'm supposing some testing with push notifications was done in the recent past. Is that the case? Or is it just me turning "Poll notifications" on and totally forgetting about it?
@Kaartic, good question, didn't even think about which page it was put on. It's not part of the suggested edits feature and the information should probably be moved. It's just that this is where we've put all our updates for Android of late and habit is a dangerous beast.
As far as I'm aware, we haven't been playing with push notifications – we only recently figured out we were going to do it at all – but @CGauthier (WMF) can probably give you a more definite answer.
Thanks for the questions @Kaartic. We have not been experimenting with push notifications in the alpha app - any notification you got will be an Echo notification with our current polling method. I am happy to move the information about the new push notifications, though I'm not sure anyone actually checks the main Android page. Suggestions for where people might see it?
Thanks for the clarifications both!
My suggestion would be to move the content about "Push Notifications" to a sub-page of Wikimedia_Apps/Team/Android.
If we really want the audience of the AppEditorTasks page to know about the new push notifications page we could add a banner to the tap of the page stating that we're planning to introduce the new push notifications feature and link to the new sub page from there. Using distraction to gain attention to a feature that distracts. Don't mind the last sentence, just playing with the words ;-)
I don't think it will have enough views and information to merit a separate page. Maybe it's better to rebuild /Android to fill that general role, in that case – I think more people will see it there, than if we hide it away in its own subpage.
Suggested Edits on Wikidata articles that already have descriptions
https://www.wikidata.org/w/index.php?title=Q78641470&oldid=1169950833 is not adding a description where there wasn't one already but changing an existing one. Is that supposed to happen? A duplicate article was merged two days prior which might have to do with this.
Tack för rapporten.
We'll take a look.
Yeah, this should be because of the duplicate article merging with the first one. We have no obvious solution right now, but it should at least not be a common occurrence.
Discussion about structured discussions.
So much for this. What kind of talk page doesn't have an edit button? I manually constructed a link to https://www.mediawiki.org/w/index.php?title=talk:Wikimedia_Apps/Team/Android/AppEditorTasks&action=edit§ion=new but didn't get the chance to add a new section. If you want feedback, please enable a normal talk page instead of this bizarre setup. Nyttend (talk) 21:41, 15 July 2019 (UTC)
This talk page is pretty normal and you created a new topic. If you want to create another one, you need to write in the input with the placeholder "Start a new topic".
Hi Nyttend! If there's something that you for some reason can't post here (e.g. need to structure galleries in a way that's difficult to do here for your feedback), you can create a user subpage and link it here, or simply post on my talk page.
(Side note: It was a pretty long time since all talk pages looked the same across the Wikiverse, I'm afraid – Structured Discussions (this solution) can be found across varying wikis, not just mediawiki.org but also e.g. community discussion pages on Catalan Wikipedia. There are pros and cons: less freedom to structure the page to look exactly like you want it to, of course, but far easier to post on mobile, more friendly to newcomers and by far easier to keep track of specific discussions on a busy page since you can get pings for anything written in an individual discussion, instead of putting the entire page on your watchlist. If you're interested in the future development of talk pages, check out Talk pages consultation 2019.)
Feedback about Suggested Edits v3
Just wanted to share some feedback about the v3 of Suggested edits:
- The idea of "moving the feature to the bottom navigation for logged-in users" is a nice one. It would be nice to have to quick-access to the feature. I especially prefer this over the Nearby in the bottom navigation bar as I have never happened to use the Nearby feature.
- The screen shown when the feature is paused looks good. On observation, I think the page directs users to external wiki pages to learn about improving their editing skills. It's a good start but it would be great if it was possible to the user to improve their skills within the app' itself. The in-app experience would be more natural, in my opinion.
- The screen shown when the feature is permanently blocked for a user could use some improvements. Pointing the user to some links that help them to improve their editing skill is useful. But the links seem to be the same as those shown when the feature is blocked. I suppose the user would have already seen the "feature is paused" screen before they see the "feature permanently disabled" screen. So, I don't think they are of much help in this case. Instead it would be better to point them to somewhere else _more helpful_ for this particular case.
- Also I was just wondering , is there any way in which the user would be able to unblock himself from permanent blocking? One thing that comes to my mind is, showing better edit quality for some prolonged time.
Thanks @Kaartic for these very useful comments. A brief reply to your points:
- You're right that we will direct people to external wiki pages. This means we can keep the content up to date, and more experienced editors in the Wikidata and Commons communities will be able to help us improve the editing FAQs to make sure that the information is correct, relevant, and up-to-date. This would be harder if we were to do, for example, some sort of walk-through in the app. A tradeoff we are making, as you correctly identify, is that it might be a tiny bit awkward to go to an external page for this information.
- Can you suggest anywhere that might be more helpful to send people for whom the SE feature is permanently disabled? We could make a different help page with some additional info - any suggestions of what might be useful to people in this situation?
- This is something we've been thinking about for a later phase. I like the idea of allowing people back in if they prove themselves in some other venue - and of course we want to include everyone who genuinely wants to make the projects better, and tries to improve their edit quality. We will come back to the community to discuss re-enabling thresholds a little later this fiscal year. (Meanwhile, the people for whom the feature is disabled under our current very restrictive system only make up 1-3% of folks who have ever edited through SE, so we are not excluding huge numbers of folks, thank goodness!)
Thanks for looking into my feedback and getting back :-) And excuse me for the late reply.
> Can you suggest anywhere that might be more helpful to send people for whom the SE feature is permanently disabled? We could make a different help page with some additional info - any suggestions of what might be useful to people in this situation?
I'm not sure I actually know of an appropriate place to send them now. In the case of article descriptions, may be pointing them to a more comprehensive guide for descriptions might be useful e.g., the guide in Wikidata. Also, I do think that your idea making a separate page with some more-specific additional information that would help them improve does sound good. It might be useful to some points in there such as:
- A tutorial that walks them through the process of adding appropriate descriptions might be useful. I imagine such a tutorial to show them some articles that are in need of a description and then show them how to make a proper description. It would also be nice to present some tips and tricks to form descriptions. This might help them correct their mistakes and improve themselves.
- What steps they can take do to re-enable the feature (of course, after that is made possible in a later phase)
Also, an off-topic but a question related to Suggested edits, has the restriction that you need to have done 50 edits to unlock other editing tasks such as "Translate article description" and "Add image captions" been changed? I ask this as I am now able to access all the Suggested edit options although I just have 24 contributions. P.S. I'm currently using Wikipedia Alpha version 2.7.50300-alpha-2019-10-15.
Hi Kaartic! Yes, we have changed it in the very latest version. The feature still requires you to be logged in, but drops the previous edit requirements. We've updated the FAQ based on some feedback we've received - including yours! Please let us know what you think. This spring, we will experiment with more tutorials in-app, and see if those help folks. We appreciate all your help and feedback very much.
When you say FAQ, I suppose you mean the page that opens when you tap on the 'i' icon in the 'Suggested edits' page in the app. Assuming it is, here's some feedback about the content.
The content itself is great! I find it totally accessible with simple and easy to read vocabulary, which is very nice. I like the way things are explained like the explanation for 'alt' text. Great work!
I know that I've said this before but I still think that it would be nice if some basic content is shown in the app itself when clicking the 'i' icon. That would help the users get an initial idea. They can then be pointed to the external wiki page for more information about 'Suggested edits'. I think that would be a better user experience than the current one which opens the external page on clicking the 'i' icon. I find the current experience to be a bit surprising as I didn't expect it open an external link.
: Showing the contents of the "What is Suggested edits?" section and a brief introduction to some "Contribution opportunities" would be nice.
There are no older topics