Last modified: 2014-05-14 16:30:58 UTC
https://en.m.wikipedia.org/wiki/Barack_Obama reads: --- Last edited 3 days ago by Aquillion --- Someone pointed out to me that the username really isn't relevant. I'm not sure why it's included. When a page was last updated may make sense to include. Who last updated the page is irrelevant and articles are intentionally unsigned.
Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/Cb9KaWn7
I'm not sure what the problem is here or what your arguments are for not showing it... You can read about the motivation around this here http://blog.wikimedia.org/2014/05/02/the-wikipedia-editors-behind-the-curtain/
(In reply to Jon from comment #2) > I'm not sure what the problem is here or what your arguments are for not > showing it... It's not relevant to the article to display who the last editor was. For example, if I visit <https://en.m.wikipedia.org/wiki/USS_Peacock>, I see: --- Last edited 1 year ago by Addbot --- It may be helpful to know that this page has not been edited in a year, but what value is provided by knowing that this page was lasted edited by "Addbot"?
It's a simple (albeit incomplete) window to who's working on the article. It's a step towards making people realize wiki pages don't magically appear. People work on them. It might be useful to exclude bots.
As mentioned in comment 0, it's also a fairly fundamental principle of Wikipedia articles that they are unsigned. By affixing a username to the top of the article, very similar to a byline, MobileFrontend is violating this principle.
It is not a signature, any more than https://en.wikipedia.org/w/index.php?title=Barack_Obama&diff=cur&oldid=prev is. You haven't yet shown that ordinary users confuse it with a byline. If that were the case, the wording could potentially be improved. It really doesn't use the standard byline format, which often says something like: By Firstname Lastname, Date or: Firstname Lastname, Date, City, Country Bylines don't have qualifications like "Last edited by". They also don't change over time (with rare exceptions). Some of the people who actually look at this line will notice that it changes as the article does.
I believe both Matt and Jon have sufficiently explained the rationale for this feature (thanks, guys!), so I'm closing this.
(In reply to Maryana Pinchuk from comment #7) > I believe both Matt and Jon have sufficiently explained the rationale for > this feature (thanks, guys!), so I'm closing this. Uh, no.
(In reply to Matthew Flaschen from comment #6) > It is not a signature, any more than > https://en.wikipedia.org/w/index.php?title=Barack_Obama&diff=cur&oldid=prev > is. I'm not sure what you're responding to with this irrelevant link. Nobody mentioned a signature except you. > It really doesn't use the standard byline format, which often says something > like: > > By Firstname Lastname, Date > > or: > > Firstname Lastname, Date, City, Country It includes a date and a name. It's pretty close to a byline. It's almost identical to your first example with the exception of the text "by". What's the rationale for including the username? I don't believe [[mw:Extension:LastModified]] or any previous iteration did this, with good reason.
(In reply to Matthew Flaschen from comment #4) > It's a simple (albeit incomplete) window to who's working on the article. This isn't true. How does the text "Last edited 1 year ago by Addbot" offer any window into "who's working on the article"?
MZMcbride if something is not clear to you, please argue more concisely than 'Uh, no.' You're spamming my inbox and your arguments are currently lost on me.... Links to any discussions, this 'fundamental principle of Wikipedia' you talk of and evidence that users confuse it with a byline would be useful. You say Matthew's link is irrelevant but you are yet to provide any yourself. Marking as unconfirmed until this has happened as this bug is unactionable and unclear. Thanks.
(In reply to Jon from comment #11) > MZMcbride if something is not clear to you, please argue more concisely than > 'Uh, no.' You're spamming my inbox and your arguments are currently lost on > me.... If you wish to unsubscribe from this bug, you can use the toggle above near "CC List". > Links to any discussions, this 'fundamental principle of Wikipedia' you talk > of and evidence that users confuse it with a byline would be useful. You say > Matthew's link is irrelevant but you are yet to provide any yourself. [[Wikipedia:Signatures]] (as an example) mentions this principle in the intro: --- When editing a page, main namespace articles _should not_ be signed, because the article is a shared work, based on the contributions of many people, and one editor should not be singled out above others. --- > Marking as unconfirmed until this has happened as this bug is unactionable > and unclear. Thanks. This ticket is perfectly actionable: remove the authorship information from this strapline. This is an easy task, so it's marked accordingly.
MZMcbride.. you're behaviour will not do anything in resolving this bug. The product owner Maryana has said this is a WONTFIX. Haven't we discussed this before and that this behaviour is not acceptable nor helpful? I'm disappointed this is happening again. I'm now muting this conversation in my inbox as suggested - probably the only useful contribution you've made in this thread.
As explained at http://blog.wikimedia.org/2014/05/02/the-wikipedia-editors-behind-the-curtain/, the rationale for surfacing authorship information is to help transition readers into editors. Getting more editors increases the depth and quality of Wikipedia. No evidence has been provided that a "Last edited" statement is confusing, nor would I expect it to be. The issue of how "anonymous" Wikipedia articles should be is not a proper subject for Bugzilla discussion. That would be better discussed on meta, a mailing list, or in an RFC. Reopening the bug isn't going to accomplish anything except creating extra cruft in Bugzilla. Even if I completely agreed with your argument, a single Bugzilla bug is not going to be sufficient for reversing the current trajectory of the product, which is to "humanize" Wikipedia by surfacing more information about editors in the interface. In order for the PMs to agree to your course of action they would have to rethink that trajectory. In other words, this isn't really a bug, but a fundamental difference of opinion about the interface. Such a difference of opinion is not going to be settled in a Bugzilla discussion. That said, I would welcome having a discussion about the issue of surfacing authorship, just not here.
(In reply to Jon from comment #13) > MZMcbride.. you're behaviour will not do anything in resolving this bug. The > product owner Maryana has said this is a WONTFIX. Jon, you want "your", not "you're", and Maryana is as much a product owner as I am. And you already know this. (In reply to Ryan Kaldari from comment #14) > No evidence has been provided that a "Last edited" statement is confusing, nor > would I expect it to be. Putting your name at the top of something is a basic means of indicating ownership. Any kid in grade school knows this. The "Last edited" statement is certainly confusing when it's discussing a non-edit, but I'll file a separate bug report about that. > The issue of how "anonymous" Wikipedia articles should be is not a proper > subject for Bugzilla discussion. That's not really the discussion here. A particular part of a particular feature should be removed. That's what this bug is about. > That said, I would welcome having a discussion about the issue of surfacing > authorship, just not here. Well, you're not quite interested in having a discussion... if you were, you would've had one prior to deploying this feature to the live mobile site. :-) I'll start a discussion at [[Wikipedia:Requests for comment/Mobile site strapline]]. In the meantime, Rome won't burn if this bug stays open for more than a day. Please stop aggressively wontfixing bugs you happen to disagree with (cf. [[mw:User:MZMcBride/Bugs]]).
(In reply to MZMcBride from comment #15) > The "Last edited" statement is certainly confusing when it's discussing a > non-edit, but I'll file a separate bug report about that. Filed as bug 64937.
Is there a ticket about showing the last editor also on non-mobile versions? Because on non-mobile en.wp I see "This page was last modified on 28 February 2014 at 06:49." in the footer.
(In reply to Andre Klapper from comment #17) > Is there a ticket about showing the last editor also on non-mobile versions? I don't know of any such ticket. I was recently considering creating a tracking bug that would collect incongruities between desktop and mobile. > Because on non-mobile en.wp I see "This page was last modified on 28 > February 2014 at 06:49." in the footer. Yep. That's been there for a long time. There's an ongoing tangential discussion about whether to make that text a link at bug 64312.
Removing the "easy" keyword while discussion continues.
>Please stop aggressively wontfixing bugs you happen to disagree with The bug was closed because it is not actionable. It is not actionable because there is not enough agreement that it is, in fact, a bug. Whether or not Jon or I agree with the bug is completely irrelevant. We're just trying to inform you that the Product Owner (http://en.wikipedia.org/wiki/Scrum_%28software_development%29#Product_Owner), which is in fact Maryana, has no intention of changing the text, as the decision to include the last editor was made with deliberate intention and is not considered a bug by the WMF. The purpose of the WONTFIX status is to indicate exactly this sort of situation. The status can change in the future, but right now that is the correct status.
(In reply to Ryan Kaldari from comment #20) > We're just trying to inform you that the Product Owner > (http://en.wikipedia.org/wiki/Scrum_%28software_development%29#Product_Owner), > which is in fact Maryana, has no intention of changing the text, as the > decision to include the last editor was made with deliberate intention and is > not considered a bug by the WMF. It should be noted here that your comment is a gross misrepresentation of both Wikimedia development and the use of wontfix. > The purpose of the WONTFIX status is to indicate exactly this sort of > situation. The status can change in the future, but right now that is the > correct status. No, this is plainly wrong. This is not, and has not, been the purpose of wontfix.
>It should be noted here that your comment is a gross misrepresentation of both >Wikimedia development and the use of wontfix. I'm not sure I understand what your interpretation of WONTFIX is. According to https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle... "RESOLVED WONTFIX when the reported problem or suggestion is valid, but any fix of the reported problem or implementation of the suggestion would be barred from approval by the project's Developers/Maintainers (or product managers, if existing)." Isn't that an accurate description of the current situation?
(In reply to Ryan Kaldari from comment #22) > I'm not sure I understand what your interpretation of WONTFIX is. According > to https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle... > > "RESOLVED WONTFIX when the reported problem or suggestion is valid, but any > fix of the reported problem or implementation of the suggestion would be > barred from approval by the project's Developers/Maintainers (or product > managers, if existing)." That seems to be Andre's interpretation of resolved/wontfix. He changed that entry in December 2013 (cf. <https://www.mediawiki.org/w/index.php?title=Bug_management/Bug_report_life_cycle&diff=849087&oldid=848793>) and then modified it again in February 2014 (cf. <https://www.mediawiki.org/w/index.php?title=Bug_management/Bug_report_life_cycle&diff=898451&oldid=850032>). That description is probably wrong. There's certainly more nuance to wontfix than that, anyway. Resolved/wontfix typically means "we're never, ever going to do this, so stop asking." It's a means of ending discussion about (or killing) an idea. That's why it should be used with caution and consideration. It's rare for anyone to be able to give due consideration if a bug is less than 24 hours old. And as stated above, Maryana is as much a product owner or product manager as I am, except I've been around longer. :-)
>Resolved/wontfix typically means "we're never, ever going to do this, so stop >asking." That was back when we had RESOLVED LATER for "This is valid, but we're not going to do it right now." >And as stated above, Maryana is as much a product owner or product manager as I >am, except I've been around longer. :-) I honestly have no idea what you mean by this. Maryana is both a Product Manager, her job title, and a Product Owner, her software development role (in Agile-speak). And both of those roles are specifically for the mobile website.
(In reply to Ryan Kaldari from comment #24) >> Resolved/wontfix typically means "we're never, ever going to do this, so stop >> asking." > > That was back when we had RESOLVED LATER for "This is valid, but we're not > going to do it right now." Resolved/later was replaced by using lowest priority/enhancement, as I understand it. I'm not aware of any change to the meaning of resolved/wontfix. >> And as stated above, Maryana is as much a product owner or product manager as >> I am, except I've been around longer. :-) > > I honestly have no idea what you mean by this. Maryana is both a Product > Manager, her job title, and a Product Owner, her software development role > (in Agile-speak). And both of those roles are specifically for the mobile > website. I didn't capitalize either term intentionally. I don't care what Maryana's current job or Agile title is. The idea that one person (transiently) owns a MediaWiki extension is antithetical to Wikimedia's values. Maryanas (and Kenans) come and go, but the rest of us will still be here trying to ensure that Wikimedia and MediaWiki development follows Wikimedia's values of openness, collaboration, and consensus. Brutishly using resolved/wontfix as a weapon isn't appropriate. Saying "well, we're doing it this way because we decided in a private meeting one day" isn't how development decisions are made, regardless of whatever arbitrary title you or Maryana or anyone else currently has.
(In reply to MZMcBride from comment #23) > That seems to be Andre's interpretation of resolved/wontfix. The interpretation of WONTFIX had been discussed several times on wikitech-l before, having the (deprecated) use of LATER in mind, so it's not only my interpretation and it's no news. In the end, maintainers decide, and they have actively provided their arguments and point of view in this ticket. > Maryana is as much a product owner or product manager as I am So you're questioning responsibility (which is often expressed by job titles) and maintainers/PM having the "final" word on what is being implemented. Which is a high-level discussion and a rather uncommon workflow in free software projects that I've been involved in, no matter if somebody pays that maintainer/PM or not.
(In reply to Andre Klapper from comment #26) > (In reply to MZMcBride from comment #23) >> That seems to be Andre's interpretation of resolved/wontfix. > > The interpretation of WONTFIX had been discussed several times on wikitech-l > before, having the (deprecated) use of LATER in mind, so it's not only my > interpretation and it's no news. Links welcome. > So you're questioning responsibility (which is often expressed by job > titles) and maintainers/PM having the "final" word on what is being > implemented. I'm not questioning responsibility as much as I'm saying that what you're describing isn't how Wikimedia or MediaWiki development operate. I don't see others aggressively marking tickets resolved/wontfix around here. It's not standard practice, as far as I'm aware. > Which is a high-level discussion and a rather uncommon workflow in free > software projects that I've been involved in, no matter if somebody pays > that maintainer/PM or not. Wikimedia is uncommon. :-) And I don't think it's as atypical as you suggest to use common sense and collaboration rather than cheap and weak appeals to authority when making making development decisions.
This discussion beyond the topic of the bug report should be moved somewhere else, or we will repeat it again in another bug report. (In reply to MZMcBride from comment #27) > I'm not questioning responsibility as much as I'm saying that what you're > describing isn't how Wikimedia or MediaWiki development operate. The Wikimedia movement has different ways of operating, sometimes they differ and contradict each other, and still they are all Wikimedia ways. MobileFrontend is maintained by the WMF Mobile team according to https://www.mediawiki.org/wiki/Developers/Maintainers . This team has a documented process to release new features through a beta mode that, according to Jon Robson in https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Mobile_site_strapline , has shipped this feature since April 2013. This team also works in coordination with the WMF Product Management and Design teams (and QA, etc). Maryana is the product manager appointed currently for MobileFrontend, and her role is to coordinate the priorities of this product, among other things. The WMF is part of the Wikimedia movement, and therefore all of the above is part of how Wikimedia or MediaWiki development operate. MZMcBride or any other community member has the right to object to any development plan or implementation, providing constructive argumentation and eventually requesting comments from any of the many communities operating within the Wikimedia movement. Appealing to previous community discussions on signatures, pointing to inconsistencies between desktop and mobile, starting an RfC at https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Mobile_site_strapline ... are also part of how Wikimedia or MediaWiki development operate. The problems come when WMF teams and Wikimedia volunteers share all of the above together with aggressive language and aggressive use of Bugzilla status fields, one step inviting to the other in a counterproductive escalation. The structure of this report shows a pattern that will cause conflict frequently, here and in most free software projects: 00:00 Volunteer files a bug 00:10 Employee replies in disagreement - comment #2 00:26 A constructive discussion continues, a second employee joins. 01:04 A third employee joins, resolving that this report is a WONTFIX. 01:56 The volunteer reopens and continues with the discussion. At this point we have several people upset, and a growing potential to upset more the new volunteers and employees that learn about this discussion. This is no justification for anybody to question the role of anybody or to be dismissive. However, it is useful to note that leaving the bug open while the discussion is open makes everything easier, especially for product owners and lead developers. Reporters on the other hand will need to bring better arguments and find wider community feedback, either gaining support for their cause or putting themselves in evidence. In the meantime, the team members can join the community discussion as they see fit, mark this report low priority, and continue with their work and their plans until the situation is clear. Waiting can be never bad for the developer team: the feature is deployed and any feedback can be useful to improve the current situation.
