Talk:Reading/Web/Projects/Related pages/Draft RFC

Alsee, thank you so much for starting this RFC. I am a bit worried that this is too broad isn't exactly clear what is the issue that we are tackling with the feature --is it generally the path forward for related pages? In addition, the feature is still in testing phase, and the beta nature on desktop that only allows logged in users to test the feature, which does already exclude most readers, to whom this feature is directed. I believe Related pages, could be of great value to new Wikipedias and smaller ones, while our only-English conversation and RFC is only making it difficult to engage different voices (it takes time to drive wider engagement). While I am not opposing the idea of the RFC, I am a bit uncertain about the specifics of what we can achieve from it, I also wonder if you think that this is something that we can replicate for further features? Or we should better explore ways that allow early engagement in ideation phase? Again, thank you very much for putting together this document. Thanks.--Melamrawy (WMF) (talk) 14:55, 29 February 2016 (UTC) Update: Can we change the Request for Comments, into a Request for Features? Might be a new approach towards digging deep into how to make the best use of what seems to have potential for both readers and editors? A new kind of engagement for product decisions. Before boldly moving with renaming, what do you think  Alsee. --Melamrawy (WMF) (talk) 17:42, 1 March 2016 (UTC)
 * Based on your edits I have a better idea what you have in mind. The most common and easiest RFC's are a basic Support/Oppose on a proposal. The first reaction of most editors is going to be to !vote on whether they want it deployed or not. I'm going to put some thought into a significant restructuring. Alsee (talk) 18:07, 1 March 2016 (UTC)
 * Phew, I am glad we don't have a misunderstanding Alsee :), this experiment will be very helpful in shaping the way how we discuss and decide on products in a more collaborative and progressive manner. Thanks again! --Melamrawy (WMF) (talk) 18:13, 1 March 2016 (UTC)

Question. As I noted, the first thought of a lot of people will be whether they want it or not. Lets assume for the moment that the reception is very positive. If people think "looks great, we formally approve deployment now".... do you want to invite or exclude that? Alsee (talk) 19:28, 1 March 2016 (UTC)
 * Hey Alsee, so, we did announcements around the work on this specific feature since October. We got different community members from different Wikipedias engaged in the conversation on the talk page of the extension, whether by highlighting issues (fair use images, for example), asking questions (how the algorithm works), discussing the logic of the feature (see also, and related pages), and asking for specific tweaks. Why do we want to get back to square zero, if the conversation is already way ahead of this? Community rejection doesn't need an rfc to express itself. It clarifies itself since day one.  In our case here, imo, we are not in a situation of asking whether this feature is wanted or not, but we are at a stage where after initial engagement and tackling specific issues, we need to move forward, in a way that makes the product well tailored for our editing community, and educational enough for our readers.  Makes sense?   :) --Melamrawy (WMF) (talk) 21:12, 1 March 2016 (UTC)
 * Melamrawy, please please please stop doing that. During the Gather discussions you said an RFC "wasn't needed", then made a second comment that we shouldn't have one. I don't know if you realize it, but that was a big reason people got upset and started the RFC without waiting for the WMF response. Due to past tensions, particularly Superprotect, a lot of people are hypersensitive to anything that sounds like the WMF doesn't want to hear Consensus.
 * People are also hypersensitive to anything that sounds like the only option is to "move a project forward" like an unstoppable train. In your edit here you effectively said the Reading team DOESN'T want to know whether we consider this a valuable addition to enable (by your deletion of that text). You instead inserted the phrase "roll out" and TWICE said the only thing you wanted to hear was how to "move forward" with the project. I deliberately removed those phrases to avoid anyone interpreting them in the worst possible way, to prevent triggering unnecessary hostility.
 * If we are "already way ahead of this" and "Community rejection doesn't need an rfc to express itself", then you have nothing to lose and everything to gain by an RFC. The community feels respected, anyone who doesn't like the feature will know it was deployed by Consensus rather than "imposed" by the WMF, it will build trust in the WMF, and it will help heal old wounds.
 * If an RFC does reject it, Jkatz said "I see no reason why we should push on these wikis if they don't want it". You'll also be able to see why people opposed it, and if appropriate there can be further WMF-Community discussions. WP:CCC: Consensus Can Change. Alsee (talk) 23:57, 1 March 2016 (UTC)
 * Hi Alsee, I want to thank you for your edits on restructuring the page, and despite of your above reply that sounds like we have a disagreement, on the contrary I see that the edits you made to the document, show that you clearly understand my concern. My point as I elaborated, and as I see that you captured, is even after "consensus" on an rfc written in English, how do we move forward, making sure our decisions are collaborative, and that we listen to details of how each community needs to best tailor the feature?   In the feedback page, we got 29 persons interacting, by suggesting fixes, tweaks, etc. The majority of the conversation was progressive, however, the team can not claim that they now got a green light to do whatever they want to do with the feature moving next. Similar to the voting nature of an rfc, which is tricky, ending up with many "yes" votes on something written in one language, would  still leave us with a question on how to best plan and tailor a feature that many people approved? Something which I was hoping this document can help us answer, and which I think your restructuring did help.  I will make a few more edits, and please, please wish me luck that nothing will be misinterpreted :). Thank you again Alsee.--Melamrawy (WMF) (talk) 10:14, 2 March 2016 (UTC)
 * (edit conflict)I hope my last comment didn't come out harsh, and if it did I apologize. I'm happy with the the WMF's steps for community engagement. In recent discussions several community members were very hostile when it was inappropriate and unfair. It was wrong. The WMF didn't deserve that. I'm trying to avoid anything that may be interpreted badly. It's going to take time for people to believe positively.
 * (reading your new reply) Thank you for the positive comment. The multi language/community issue makes things really hard for you guys. To be honest, my first goal here is EnWiki-WMF proceess. EnWiki is by far the biggest and most developed community. By most measures it comes close to half the global community. EnWiki also shares a language with the WMF. I sincerely don't want EnWiki to "rule" over the other communities. EnWiki is a member of a community-of-communities. However EnWiki is defacto in the best and most weighty position to address these issues. I believe that building the WMF-EnWiki process is the foundation-stone for handling the multi-community challenge. The WMF is building new cross-wiki technologies, as well as the translation extension, that I hope may enable the Communities to help solve some of the multi-community challenges for you. Back to the current case, it's really hard to get the sort of feedback you need by posting links to WMF-wikis. If you want to hear from the other languages, the EnWiki post could be revised and translated/posted to the next largest wikis (however many you feel is sufficient and manageable), and there could be an open invitation for anyone to translate and post it to their own wikis.
 * Regarding "how to best plan and tailor a feature that many people approved", if we first establish a consensus that it's wanted then people will eagerly build you a document of what we want. What I'm struggling with on this RFC is that it's a awkward trying to tell people *not* to sort out whether we want it, but to still go to work on how to improve it if we hypothetically wanted it. Alsee (talk) 11:37, 2 March 2016 (UTC)

Ping Melamrawy (WMF), Jkatz (WMF). I think the current version is looking good. Most RFC's are expected to reach some sort of decision on something, but I made it This RFC has no outcome other than to generate feedback for the WMF. I think this is what you were looking for. I also want to specifically check with you on this sentence The WMF is not looking to deploy it at this time, and does not want to push it on Wikis that do not want it. It reinforces that people should give features-feedback rather than trying to !vote on whether they want it enabled now. I could easily put in a question to see if people were interested in enabling it now, but it seems you're not looking for that here? The not "push" part came from here and it will help ensure a good community reception, if that language is good with you. Alsee (talk) 23:13, 2 March 2016 (UTC)
 * Thanks Alsee, it is getting late my time here, and I would like to review and made comments in a much better state of mind.  So just acknowdging the fact that I read this, and will get back to you on a better timing of the day :). As mentioned above, I would still like to apply some changes.  Thanks--Melamrawy (WMF) (talk) 23:36, 2 March 2016 (UTC)
 * Oops. I removed two things, I had intended to comment on them here but I got sidetracked. Sorry for dropping them without explanation.
 * Can we use related pages to explore different editing modes on mobile?
 * I didn't understand the idea here, and I'm assuming others wouldn't either. I don't see how related pages could connect to editing and I don't know what you mean by "different editing modes".
 * How could Related Pages help with orphan articles?
 * I thought it would be beneficial to keep things shorter and more focused, and my impression is that this question isn't likely to go anywhere useful. If you guys feel this is significant then I guess we could add another section on the end. Alsee (talk) 20:02, 3 March 2016 (UTC)
 * Thanks Alsee. I reworded the question and the testing proposal--let me know if you are okay with it.  One thing that I struggle with is that we want feedback and we want to know what needs to change, but at this stage, we are not looking for "wouldn't it be cool if..." feedback.  It doesn't hurt, but I don't want to give the impression that this is a feature we are doubling down on and are going to spend the next year perfecting--we think it is a net positive for readers, but I am not sure I can justify spending more time for a 20%-50% improvement of the feature given our responsibilities and strategy.  I wrote under feedback "More specifically, is there anything that would need to change before you would want it on your wiki?", but let me know if you think of anyway to be clearer about that.  Again, my main concern is that I don't want people to feel that this is a wishlist of things we are going to do.
 * I really appreciate the sensitivity to the "doubling down" perception. I think people will be very happy to see the "does not want to push it on Wikis that do not want it" part. When it gets posted I'll follow it closely. I'll do what I can to shut down any inappropriate negativity, to steer things in a useful direction, and avoid any unreasonable expectations. The only changes I made were a typo fix, and adding ~ in the lower sections to separate the text from the first reply, and fixing links that would have rendered in red when posed on EnWiki. Would you like me to post it? Or would you prefer a (WMF) post? It can be posted at en:wp:Village_pump_(miscellaneous). The ombox-Draft-template should be removed, and the 4 bits in yellow should be converted to a plain rfc template and 3 regular signatures.
 * By the way, over at the community I floated the idea of opening a dedicated Village Pump page to assist WMF-Community engagement. A place where you can post new project ideas, request feedback on things, ask us questions, pretty much anything. If that idea gets some fast positive comments there's a chance we can post this RFC on it. Village_pump_(miscellaneous) tends to be low-interest assorted junk, but unfortunately this RFC doesn't fit very well into the purpose of the other Pump pages. Alsee (talk) 09:37, 4 March 2016 (UTC)
 * "we are not looking for "wouldn't it be cool if..." feedback. It doesn't hurt, but I don't want to give the impression that this is a feature we are doubling down on and are going to spend the next year perfecting". That part needs to be much clearer in the RFC.... this means, that the basic premise here is, "whats the minimum effort we have to spend to have ppl accept this feature as it is right now. A premise that in my opinion usually doesn't really work too well to build momentum, btw. but probably realistic.  Also, I think its not the right decision. Part of mothballing something should be exactly to collect such feedback and document it, for that time where u can pick it up again.. u just need to clearly designate such different requests parts of your rfc.  —Th e DJ (Not WMF) (talk • contribs) 13:48, 4 March 2016 (UTC)

Th e DJ (Not WMF), per clarification suggestion, I added We are willing to make reasonable changes if they will make the feature desirable or more valuable. It should helps set expectations on changes, and "changes if they will make the feature desirable" should help reinforce the goal, as well as reinforcing the no-doubling-down. Could you elaborate on you had in mind with "clearly designate such different requests parts of your rfc"? My initial intent was to try to keep the structure simple, but now I'm thinking this topic should draw enough motivation for people to invest significantly in multiple sections. You posted some hidden comments in the draft - I extracted them to here:
 * Keep it simple. "If u want to brainstorm with us on things for next year, go here. if u have more immediate concerns, go here —Th e DJ (Not WMF) (talk • contribs) 11:12, 5 March 2016 (UTC)


 * [click through] there is some concern that this is simply because there is an image. concern ? do we intend to say that images might distract from other related links ? Even if they did, that is not a bad thing, if quality is at least equal right ? -TheDJ
 * This is referring to concerns raised in previous feedback. There were concerns that the software-links were either redundant to, or lower quality than, human created links. There were concerns that the clickthough may just reflect cannibalization of article links. There were concerns whether it was desirable to use lower quality "clickbait" links to promote longer reading sessions / pageviews. The data seems to indicate related pages are not merely cannibalizing existing link-clicks, but the rest seems open to reasonable discussion.
 * "This is referring to concerns raised in previous feedback." i undertand, but try no to get sucked into a back and forth question answer game and projecting that back 1 on 1 on an rfc page. identify the concern raised earlier. contextualize it, give a direct answer and give a fallback scenario. that is what u present, because it is a more readable answer, that is fairer to the wider audience reading this. The person asking the original question is a different audience —Th e DJ (Not WMF) (talk • contribs) 11:12, 5 March 2016 (UTC)


 * Themenring policy on German Wikipedia. I would add to this that "objective and complete" is a fundamental subjective judgement call of course.. In many ways, u could say that algorithms could be much better at it. -TheDJ
 * "objective and complete" was my attempt to summarize a German policy I know little about. As I understand it navigation links to "States in the U.S." or "Doctor Who Episodes" are only permitted if the list is complete, and navigation links to "Famous Authors" are not permitted because they are both subjective and inherently incomplete. (BTW the algorithm seems to have a major fetish for linking J.K. Rowling, chuckle.) Strong objections were raised on the basis of this policy, but German/Russian wikis have to sort out whether this is/isn't a problem. For other Wikis it seems worthy of passing note for the global perspective, but probably not locally relevant.
 * "Strong objections were raised on the basis of this policy" as a community member, that seems like a clear example of wikilawyering over boldness and IAR to me. "i like my box, i'm staying in it". Would this feature raise questions about what a policy like the one mentioned would entail ? sure, but straight objections, simply on the basis of a policy that was written for navboxes, i can't do anything with that as a developer. My solution to that is: have the community sign on the dotted line to opt out (possible in this case I think, since it doesnt affect too many other things). —Th e DJ (Not WMF) (talk • contribs) 11:12, 5 March 2016 (UTC)


 * WMF is trying to build engagement that is scalable. I would therefore also invite communities to not just reject ideas, but to bring up their own ideas around engagement and scalability, don't be too defensive. -TheDJ
 * Fully agreed. I don't think we want to shoe-horn that in this RFC tho. I'm hoping this RFC can be a first step in developing those solutions.
 * when you have people's attention, use it. just funnel them to the right spot. —Th e DJ (Not WMF) (talk • contribs) 11:12, 5 March 2016 (UTC)


 * The Reading Team believes the sustained high click through rate on mobile suggests that users are finding it valuable enough to justify the feature. and again, i would bring up that there is no good reason, that an algorithm might not be objectively better at providing See Also's than human editors. perhaps not right now and perhaps never for FA or GA articles, but why not explore this? -TheDJ
 * Added: For some articles software might provide objectively better at links, especially as the software improves.


 * This is about availing more knowledge by offering more articles related to the topic that readers are learning about. Learn more, more effeciently -TheDJ
 * Added:, and helping them learn more efficiently.


 * For 'damaging' results, which are rare, editors can over-ride results. For 'suboptimal results', for now I think we should live with it because the readers seem to be deriving value. tsst.. come on, this should be: "Report them to us, and we will work with the discovery team, to improve the algorithms long term." -TheDJ
 * I'll leave it to the WMF whether they want to commit to some long term algorithm project. Alsee (talk) 17:49, 4 March 2016 (UTC)
 * Thanks both - Alsee (talk and Th e DJ (Not WMF).  I think it is much better now.
 * thanks for processing my comments. i'm a one handed typist atm, so its a bit fifficult to be efficient at the moment. —Th e DJ (Not WMF) (talk • contribs) 11:12, 5 March 2016 (UTC)

RFC pro con
RFC fits (because we are requesting comments here), and ppl understand what it is. on the other hand, rfc has become very much a decision/voting utility, which doesn't really seem to be what the questions here are about. perhaps we need new terminology ? Consulatation Process (CP). or Software Consulatation Process (SCP) something similar ? Just a thought. —Th e DJ (Not WMF) (talk • contribs) 13:33, 4 March 2016 (UTC)
 * Hey TheDJ, in fact if we can start this separate discussion around a new policy, in its right place, that would be wonderful --Melamrawy (WMF) (talk) 17:17, 4 March 2016 (UTC)
 * This is a bit weird to explain, but we're all essentially in the middle of doing that right now. One of the core ways we operate is that everyone is invited to Boldly do whatever needs to be done to improve and maintain Wikipedia. If pretty much everyone considers it productive and reasonable, no one complains. Often the last step is that a policy is written, merely to reflect accepted common practice. Whoever is doing the work can pretty much invent their own rules, so long as most people consider it reasonable. For some things it takes insider cultural knowledge to be able to predict what everyone will consider obviously reasonable.
 * For example I mentioned above the idea of a new Village Pump page where the WMF could post basically anything. I went ahead and created the page, but I didn't fully install it into Village Pump yet. If no objections show up I'll just go ahead and make a few edits to complete the installation.
 * Another thing we can do is open a discussion for people to start tossing out ideas on (1) what processes do we need and (2) how should they work. The new page would be the perfect place to do that, and a big part of it would be finding out what the WMF wants and needs. Alsee (talk) 19:30, 4 March 2016 (UTC)
 * Hi Alsee It is cool to see you moving forward on this. We're actually trying to think through how something like this should look from our end too-- there are specific questions we want to pose and hear ideas about, but it might make sense to collaborate.  I actually think that idealabs is a really great model--or something else that allows editors and readers (who aren't wikitext experts) to submit ideas, endorse and submit feedback.

My own long term vision on this
Wikimedia_User_Interface/Concepts/Explorer —Th e DJ (Not WMF) (talk • contribs) 12:09, 5 March 2016 (UTC)