bingle-admin wrote:

Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1377

Yes this is currently by design and may or may not be right.

I've added a design tag to get an opinion on the rationale behind it and to explore this further.

this is as designed. Do we have users commenting on this issue? The rational if i remember correctly is that many new editors (which most mobile editors are) are unlikely to know what an IP is or that it represents a person. I can see the IP shown on the detail overlay, but I think the reason for obfuscating it on this screen is reasonable.

(In reply to comment #3)

this is as designed. Do we have users commenting on this issue?

Last time I checked, I'm a user.

The rational
if
i remember correctly is that many new editors (which most mobile editors are)
are unlikely to know what an IP is or that it represents a person.

Really? How many new editors know what a watchlist is and will use it? How many will even get to the watchlist?

We're already throwing way more useless information at them like inaccurate edit counts and the fact that some users are "edit filter managers" or "course campus volunteers" (how do you expect a new user to know what that is?!).

I can see
the IP shown on the detail overlay, but I think the reason for obfuscating it
on this screen is reasonable.

Do we obfuscate IPs on desktop for new editors? No. Should we? No. Should we do the same on mobile? No. Re-opening.

Lego with all due respect please don't reopen bugs. A closed bug doesn't necessarily mean the bug will be forgotten and doesn't prevent you from providing further arguments on why it should not be closed / writing patches and getting it reopened but from my perspective as a core developer of MobileFrontend it does come as a nuisance for knowing which bugs need working on and which don't.

Also, I'm not sure if intended but your tone in the latest bug report comes across as aggressive.

I'd suggest raising a discussion on the design list for wider discussion as a better first step.

https://www.mediawiki.org/wiki/Bug_management/Bugzilla_etiquette

(In reply to comment #5)

Lego with all due respect please don't reopen bugs. A closed bug doesn't
necessarily mean the bug will be forgotten and doesn't prevent you from
providing further arguments on why it should not be closed / writing patches
and getting it reopened but from my perspective as a core developer of
MobileFrontend it does come as a nuisance for knowing which bugs need working
on and which don't.

The bug was closed as "WORKSFORME". According to [[mw:Bug management/Bug report life cycle]], that means "when the problem can not be reproduced or when missing information has not been provided". That is clearly not the case here, which is why I re-opened it.

You can adjust the priority field then, I deliberately left it as "Unprioritized" to allow people who do the most work in this component to prioritize it according to what they plan on doing.

Also, I'm not sure if intended but your tone in the latest bug report comes
across as aggressive.

It wasn't, my apologies if it did come across that way. I was trying to make the point that the line of argumentation being used is misguided and incorrect.

I'd suggest raising a discussion on the design list for wider discussion as a
better first step.

Thanks, that sounds like a good idea. I'll send an email in a few minutes.

https://www.mediawiki.org/wiki/Bug_management/Bugzilla_etiquette

It would be helpful if you could explain why you included a link to the draft, I'm pretty well aware of it.

khm wrote:

Hi,

Completely new to mobile wiki editing and this site.

Was baffled by the decision to not show the ip numbers of anonymous edits, and dismayed to not find any setting to show them.

When I finally found my way here, I was equally baffled to learn that there is no real rationale for this decision - unless I'm mistaken the above comments only say "by design".

Here's a thought for you: why don't you strive to replicate the functionality of normal wiki edits (taking into account the different format and medium of mobile edits) and only deviate from this IF ASKED TO.

In other words, follow the same functionality as of the main wiki site (=show the ip numbers of anons) until and unless you're inundated by complaints.

This is because in general it's safe to assume nobody cares enough to register an account and navigate through the non-trivial inner workings of this bug reporting site. So instead of making up your own minds and changing stuff only when people start complaining, how about you simply make mobile wiki work like regular wiki until and unless you start getting complaints...?

Currently, I'm looking at my watchlist.

It's a long list of "anonymous edit" with no way to tell one edit from another. Likewise, when another editor reverts the edits of 100.200.300.400 I have no way to tell which of these edits he has reverted! All of them? Just one?

I can't tell, unless I move over to the regular interface.

I call this a design failure, but more generally I'm concerned you are not having the right target in your mind.

Please don't make design decisions that deviate from regular wikipedia (unless motivated by the different form factors). Please strive to make mobile wiki an exact copy of the (functionality of) regular wiki, or risk instances where your work becomes *useless*, such as in this instance. Please don't use mobile wiki to "place your mark" upon an application. Nobody wants mobile wiki to become an unique piece of software; we want the same old Wikipedia but rejigged for smooth mobile operations!

Since you have explicitly asked for the bug not to be reopened, I will delay doing so for a tenday or so, giving you time to proceed according to your preferred work channels instead. (Just give me a heads-up that this comment has been read somehow, 'kay?)

@CapnZapp the original rationale can be found in comment 3 (#c3)

This has been revisited recently and is now shown as to editors it /is/ important and we are currently working on a revert or undo feature which will need this.

See http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:History/Selenium_wikitext_editor_test

I imagine the solution will morph over time.

khm wrote:

Thank you.

I appreciate your link. However, when I try it on the english wikipedia, my watchlist still shows only the completely useless white box with a closed eye smiley and the text "Anonymous user" in red.

Now addressing everyone in general:

I read comment #3 and how it says "this is as designed. Do we have users commenting on this issue?"

This is fundamentally wrong in my opinion. Please don't make users have to comment on the design before you give mobile wiki the same functionality as regular wiki.

Users generally don't comment. Not because they like and approve of your design decisions, but because even knowing about the existence of this bugzilla site is way too much to ask of the regular wikipedian. That's mistaking laziness or lack of know-how for approval, which is misleading at best and definitely not something to base your priorities on.

Instead, please always assume users (or at least logged in editors) want, need and expect the same functionality regardless of platform without having to say so.

Not just in this particular case. Please change your overall viewpoint so that this doesn't need to happen over and over again. If you absolutely need to make your unique mark on the software you design, choose another project than this. Mobile wikipedia should just be a tool to access general wikipedia on the go, it should not be something with its own set of capabilities, unless absolutely mandated by the different format.

In short: you should not change this functionality because I happen to be able to jump through the hoops necessary to make these comments, or because others do. Don't listen to developers - anticipate the needs of users!

You should change the functionality because you realize the wisdom of not making mobile wikipedia a special snowflake. It is but a utilitarian tool where your efforts should go unnoticed when the public find them useful. Indeed, that someone like me should ideally not even realize mobile wikipedia is a different project from regular wikipedia.

Thank you.

PS. I definitely agree with Legoktm the current status "RESOLVED WORKSFORME" to be wholly inappropriate, and I'd like to remind y'all that I would still like a good rationale why cases should remain closed? If and when the linked effort goes live, the status might remain "resolved" but never because it "works for me": it's a clear lack of functionality (and a worrying indicator of wrong perspective). Personally (looking at the bug report life cycle) I'd like to assign the status to "REOPENED" and then "RESOLVED FIXED" or possibly "RESOLVED DUPLICATE".