Tryptofish (talk | contribs) →What is Flow?: oh well |
MPinchuk (WMF) (usurped) (talk | contribs) →What is Flow?: cmt |
||
Line 234: | Line 234: | ||
:::::: Well, you sure do not seem to be close to persuading or befriending anyone who does not agree with you yet... Then again - I guess that is not your goal... --[[User:Martynas Patasius|Martynas Patasius]] ([[User talk:Martynas Patasius|talk]]) 01:30, 23 September 2013 (UTC) |
:::::: Well, you sure do not seem to be close to persuading or befriending anyone who does not agree with you yet... Then again - I guess that is not your goal... --[[User:Martynas Patasius|Martynas Patasius]] ([[User talk:Martynas Patasius|talk]]) 01:30, 23 September 2013 (UTC) |
||
:::::: Given the shotgun spray of mischaracterizations and argumentative fallacies that have peppered your replies thus far, Jorm, which Martynas has been able to sidestep with the easy grace of a ballet dancer, no, it does not appear that there is. — [[User:Scott Martin|'''<span style="color:#000">Scott</span>''']] <span style="color:#900">•</span> [[User talk:Scott Martin|''<span style="color:#000">talk</span>'']] 11:27, 23 September 2013 (UTC) |
:::::: Given the shotgun spray of mischaracterizations and argumentative fallacies that have peppered your replies thus far, Jorm, which Martynas has been able to sidestep with the easy grace of a ballet dancer, no, it does not appear that there is. — [[User:Scott Martin|'''<span style="color:#000">Scott</span>''']] <span style="color:#900">•</span> [[User talk:Scott Martin|''<span style="color:#000">talk</span>'']] 11:27, 23 September 2013 (UTC) |
||
* '''Comment:''' I added some info on the guiding principles of the Flow project and Core features development in general. I'm also going to work a bit on fixing up the Rationale section and synthesizing some of the background research. What I'm hearing here is that some people are not convinced that talk pages are one of the "barriers that could preclude people from accessing or contributing to our projects." I'm guessing that's partly due to the fact that the citations to back this statement up are scattered over a number of pages and wikis. If you're still unconvinced even with these citations and feel we should not work on this project, you're welcome to continue leaving us feedback; however, it's unlikely that anyone from the development team will respond, since there's not much to say at that point. |
|||
: What we will gladly respond to – and not just with words, but with actual design and development of features – is feedback from anyone who believes that discussion and collaboration can be improved on Wikipedia and offers us ideas, suggestions, even scathing critiques that help keep us working toward our guiding principles. You may not realize this, but if you actually care about improving the discussion system on Wikipedia, you have tremendous power and resources at your fingertips right now – use them :) [[User:Maryana (WMF)|Maryana (WMF)]] ([[User talk:Maryana (WMF)|talk]]) 21:02, 23 September 2013 (UTC) |
Revision as of 21:02, 23 September 2013
This page has archives. Sections older than 30 days may be automatically archived by Lowercase sigmabot III when more than 5 sections are present. |
Smaller and offsite announcements/mentions
Continued from Wikipedia:Flow#Announcements
- Wikipedia:Wikipedia Signpost/2013-03-11/Technology report - Article Feedback tool made opt-in only (brief)
- Wikipedia:Wikipedia Signpost/2013-01-21/Technology report - First Quarterly Review makes for interesting reading (brief)
- Wikipedia:Wikipedia Signpost/2012-12-31/Interview - Interview with Brion Vibber, the WMF's first employee (brief)
- Wikipedia:Wikipedia Signpost/2012-09-10/Technology report - August engineering report published (brief)
- Wikipedia:Requests for comment/Article feedback - January 2013 (numerous brief mentions)
- http://blog.wikimedia.org/2013/05/02/wikimedia-engineering-april-2013-report/#Editor_engagement_features
- http://blog.wikimedia.org/2013/04/12/wikimedia-foundation-report-march-2013/#Editor_engagement
- http://blog.wikimedia.org/2013/03/13/wikimedia-foundation-report-february-2013/#Editor_engagement
- http://blog.wikimedia.org/2013/03/12/engineering-february-2013-report/#Editor_engagement_features
- http://blog.wikimedia.org/2013/02/17/wikimedia-foundation-report-january-2013/#Editor_engagement
- http://blog.wikimedia.org/2013/02/07/engineering-january-2013-report/#Editor_engagement_features
- http://blog.wikimedia.org/2012/12/06/engineering-november-2012-report/#Architecture_.26_Platform_support
- http://blog.wikimedia.org/2012/10/03/engineering-september-2012-report/#MediaWiki_infrastructure
- http://blog.wikimedia.org/2012/09/04/engineering-august-2012-report/#MediaWiki_infrastructure
- WMF Editor Engagement mailing list (most of May 2013)
- Wikimedia tech ambassadors mailing list, 16 May 2013
Supported Wikitext
What wikitext will and will not be supported is a difficult question for me because there is an inherent problem with any answer, and that is "I can only speak to what Parsoid is capable of today" and not what it will be capable of in six months or even a year. I don't want to say things like "sure, this will work" and then later be wrong so I've been hemming and hawing here and there and that kind of sucks. However, I've had several conversations over the past couple days (my time has been compressed this past week due to several all-day engagements), but I've got some answers.
First, it's probably easier to ask "what will not be supported" rather than "what will be supported." And it turns out, there's a whole page about the limitations of Parsoid. As you can see, much of that is broken wikitext - stuff you shouldn't be doing anyway. Some of it (using templates to define table structure) is listed as "tricky, but solvable", and I'm informed that most of those issues will be solved within the next six months or so.
If you're curious, there is a sandbox that you can play with and test arbitrary wikitext in form to see output modes (also how it gets saved, but that shouldn't be a concern).
Hope this helps.--Jorm (WMF) (talk) 19:47, 24 July 2013 (UTC)
- Oh, yeah: the question about SUBST'ing things vs. non-SUBST'ing is actually not finalized yet; I don't have an answer for that.--Jorm (WMF) (talk) 19:48, 24 July 2013 (UTC)
- Thanks, that's very helpful in understanding (at least for me). Given that (as far as I understand) we are concerned here with what could loosely be called discussion pages, as opposed to article space itself, I do not see these limitations as presenting an impediment to worthwhile communications amongst editors. --Tryptofish (talk) 20:20, 24 July 2013 (UTC)
- Could you please acknowledge that you understand how partial wikitext support (i.e. any form of wikitext processing that is redirected through Parsoid) would disrupt current community practices? So far I've not seen you acknowledge that disruption, and given that you'll be designing the new cooperation platform, it would be great to know that you at least know exactly what you're "taking away from Peter". Diego (talk) 21:09, 24 July 2013 (UTC)
- No it does not help. Because you still have it upside down. We need full rendering - of everything, including the ugliest css-hacks or misappropriation of templates. Your job is to provide it. Period. I don't care how difficult it is, your code won't be rolled out until it can deliver. rgds --h-stt !? 13:01, 25 July 2013 (UTC)
- Right. So, as said before, "full rendering" in comments and posts with Flow is not likely to happen. If you'd like to help out with the project, that's great, but this kind of comment doesn't get us anywhere.--Jorm (WMF) (talk) 16:30, 25 July 2013 (UTC)
- Jorm, if the user base say that the software is completely unsuitable for them unless X, then your choices are 1. Deliver X, 2. Do tests to see if they really miss X, 3. Stop development, or 4. Spend a lot of time creating something that will never be used. Adam Cuerden (talk) 16:50, 25 July 2013 (UTC)
- I agree with H-stt and Adam that full rendering of arbitrary (correct) Wikicode (not limited to that allowed by Parsoid, but any Wikimarkup which generates valid HTML) is required in talk pages; but it doesn't have to be part of Flow. It would be adequate that any Flow message allow the inclusion (not link to, but include) an "article" in a scratch space. And ... talk page messages should be subst'd; talk page copies of proposed article text should not be. As long as page can be rendered in article-space, it must be able to be discussed in the user-talk-page equivalent. — Arthur Rubin (talk) 17:26, 25 July 2013 (UTC)
- Agreed with Arthur. As long as some method of delivering the functionality is there, and it doesn't cause undue disruption, it should be fine.
- In all honesty, I think we're dealing a little too much in abstract here. Flow doesn't need the ability to deliver perfect Wikimarkup all the time; it just needs a method of gracefully handling the few situations where that ability is vital, which is not quite the same thing. There's a thousand different acceptable ways to make this work, from some equivalent of <nowiki> tage - <noflow>, say, to incorporating a wikitext markup interpreter box as a type of workflow meant for that purpose. You might even find that people are amenable to using subpages for that purpose if they can make those subpages have "sticky links", if you're familiar with forum terminology. Perhaps transcluding subpages is an option: if they look a little funny in Flow, people can still jump over to the subpage and see the full functionality.
- Any of those methods and many more would probably be perfectly fine. Adam Cuerden (talk) 19:19, 25 July 2013 (UTC)
- I agree with H-stt and Adam that full rendering of arbitrary (correct) Wikicode (not limited to that allowed by Parsoid, but any Wikimarkup which generates valid HTML) is required in talk pages; but it doesn't have to be part of Flow. It would be adequate that any Flow message allow the inclusion (not link to, but include) an "article" in a scratch space. And ... talk page messages should be subst'd; talk page copies of proposed article text should not be. As long as page can be rendered in article-space, it must be able to be discussed in the user-talk-page equivalent. — Arthur Rubin (talk) 17:26, 25 July 2013 (UTC)
- Jorm, if the user base say that the software is completely unsuitable for them unless X, then your choices are 1. Deliver X, 2. Do tests to see if they really miss X, 3. Stop development, or 4. Spend a lot of time creating something that will never be used. Adam Cuerden (talk) 16:50, 25 July 2013 (UTC)
- Right. So, as said before, "full rendering" in comments and posts with Flow is not likely to happen. If you'd like to help out with the project, that's great, but this kind of comment doesn't get us anywhere.--Jorm (WMF) (talk) 16:30, 25 July 2013 (UTC)
Instead of arguing about abstracts (which is going nowhere), we need specific examples.
(This has been discussed in a large variety of locations, partially due to multi-posting by some editors. I'll try to summarize the fragmented discussion so far...)
The core issues are summarizable as:
- We, the editors who continue to primarily "Edit source", need a way to copy-and-paste content from the edit-window into a Flow-discussion. We also want to continue to type the markup that we're accustomed to, that effortlessly flows from our fingers.
- Article-content is often discussed in usertalk, therefore it needs to be considered even before the beta/opt-in stage.
- The content we post, needs to display the same way as it does in an article, because we're frequently discussing the visual-aspect of formatting and layout, and diagnosing errors or glitches.
Here are some specific examples, one for each type of content. The descriptions I added are abstract, not diff-specific.
- [1] Demonstrating new templates.
- [2] Discussing IPA technicalities, with IPA templates and examples probably copied from an edit-window.
- Done
- Done
- [4] Numerous {{tl}} templates.
- [5] Copying example code (and embedding it in a < nowiki > or < code >), to explain something.
- Done
- [6] Table-Code excerpt from article.
- Done
- [7] Template:Gi/Tq used to highlight quoted remarks that are being replied to.
- Done
- [8] Magic word {{NUMBEROFACTIVEUSERS}}
- Done
I went through about 40 usertalk pages, and those were the clearest and most diverse examples I saw.
If Flow's still hypothetical (therefor hard to predict features of) fallback-editor, or even the VE-editor-after-months-more-development, supports all of these instances, without us changing our typing-habits drastically (or at all), I believe that will satisfy all the confusion and concern. At the very least, it gets a brief & clear set of examples in front of the devs' eyes (for them to keep in mind over the coming months), rather than abstract requests for "everything". –Quiddity (talk) 20:19, 25 July 2013 (UTC)
- I made a handy gallery of screenshots :) There were a couple things I couldn't get to work in the prototype, but I suspect those are just templates Andrew hasn't got preloaded into his Mediawiki instance. Soon we should have this prototype out on a test environment where everyone can test it out. Maryana (WMF) (talk) 23:37, 19 August 2013 (UTC)
-
IPA template
-
nowiki example markup
-
gi/tq template
-
magic word
- Perhaps I could add one more example, from my own talk page:
- [9] Copying mathematics text from an article to ask a question about the notation employed.
- Will it continue to be possible to do that? Spectral sequence (talk) 21:18, 10 August 2013 (UTC)
-
Math!
- Yep :) Just for you, Spectral sequence. Maryana (WMF) (talk) 23:41, 19 August 2013 (UTC)
- Thank you, not just me, it's the whole community of mathematics editors. Spectral sequence (talk) 05:44, 20 August 2013 (UTC)
- Plus the community of physics editors, plus a sizable share of the community of engineering editors.-----<)kmk(>--- (talk) 23:52, 26 August 2013 (UTC)
- Thank you, not just me, it's the whole community of mathematics editors. Spectral sequence (talk) 05:44, 20 August 2013 (UTC)
- Yep :) Just for you, Spectral sequence. Maryana (WMF) (talk) 23:41, 19 August 2013 (UTC)
OK, let's add some additional parts of "semi-wikitext" (that is, things that might not be "real" types of "wikitext", but are strongly related) that have been mentioned here on this page:
- Unblock requests. Since, as far as I understand, the "Flow" is planned to be deployed for some of the user talk pages first, the unblock request will have to be somehow compatible with "non-Flow".
- "Diffs". The important part is getting the "diff" (adding a link should be trivial, right..?).
And something that hasn't been mentioned:
- Checklists used for collaboration. Just like one you, Maryana, used just above ([10]). The problem: how is it going to be edited if you prefer to let edit posts of other users just for administrators..?
- Tables with "nice" formatting ([11]). The example is from the article talk page, but it could happen in the user talk page as well (originally the proposals I was answering there were even given via E-Mail).
- Succession boxes (like [12]). The problem is that, for example, Template:S-start ([13]) does create unbalanced HTML tags ("TABLE").
So, are those things possible in "Flow"..? Are they planned to be supported..? --Martynas Patasius (talk) 18:14, 20 August 2013 (UTC)
- Please keep in mind that whether or not Maryana prefers to only let administrators edit the posts of other users, it is not Maryana's place to make that decision. It has already been established that Flow will allow the various wikis that use it to configure this as they see fit, and it has already been established that this is a decision to be made by the English Wikipedia community through consensus. Consensus can change, but right now the overwhelming consensus is that anyone can edit the posts of other users.
- That being said, what if we change our minds and decide to only let admins edit other's comments? If we do that, how will we do things like checklists used for collaboration that we are doing now by editing each other's comments? Perhaps Flow could give us a way to make one particular comment editable by anyone? --Guy Macon (talk) 21:18, 20 August 2013 (UTC)
- You're describing what we refer to as "Scratchpads" or "Collaborative Editing Areas".--Jorm (WMF) (talk) 21:39, 20 August 2013 (UTC)
- "Please keep in mind that whether or not Maryana prefers to only let administrators edit the posts of other users, it is not Maryana's place to make that decision." - yes, perhaps. That's why I wrote "prefer". But still, someone who has to write specifications (or anyone else developing the software) should be reminded of the great number of necessary features. --Martynas Patasius (talk) 22:40, 20 August 2013 (UTC)
- Re: unblock requests - they've decided to make the initial roll-out not in all of usertalk namespace, but only to (one or a few) Wikiproject discussion pages - see Wikipedia:Flow#Timeline.
- Re: diffs - do you mean page diffs (as I linked above, which are basically just bare or named URLs), or something else? URLs should be utterly simple to handle, hence I didn't bother to include them in my samples of types.
- Re: Checklists - answered above by Guy and Jorm.
- Re: Tables - They're working on it, and are aware that we need it.
- Re: Succession boxes, I'm not sure, but I would assume that parsoid can handle these. I believe it's unbalanced templates, in the sense of "We have the start, but not the close", that is problematic, and even that is being looked at, per mw:Parsoid#Architecture
- HTH. –Quiddity (talk) 23:02, 20 August 2013 (UTC)
- "Succession boxes" are unbalanced templates; {{S-start}}, etc. They should be allowed in any Flow message (somehow) in any useful system, but they probably don't meet Parsoid. — Arthur Rubin (talk) 14:25, 21 August 2013 (UTC)
- Yes, but - {{S-start}} is/should always be followed by {{S-end}} which means the code closes itself properly (ie. no malformed HTML is generated). Therefore if used properly they should be fine? If that doesn't cover it, then that link I included should, which says "Templates are also be expanded at this stage, which makes it possible to still render unbalanced templates like table start / row / end combinations." –Quiddity (talk) 20:22, 21 August 2013 (UTC)
- "Succession boxes" are unbalanced templates; {{S-start}}, etc. They should be allowed in any Flow message (somehow) in any useful system, but they probably don't meet Parsoid. — Arthur Rubin (talk) 14:25, 21 August 2013 (UTC)
- First of all, the point of my "additional list" was to make writing of specification easier. Even things that are relatively easy should be written down.
- Second, about unblock requests. If "Flow" gets deployed, at some point it will replace the user talk pages. I get the impression that this process might start with some volunteers (by the way, that would mean that people communicating with those volunteers will get no say in this decision). But some form of compatibility is necessary in any case. At the very least, the unprocessed unblock requests will have to be remade into the new system automatically. And, by the way, after hearing "Nothing is set in stone!!!" that many times, I don't think we should assume that the deployment will not start with some user talk pages... At this point I am afraid that the only thing that is "set in stone" is that "Flow" will be deployed no matter what...
- Third, about "diffs". Yes, adding a link that points to a "diff" should be trivial. However, there must be a (hopefully, simple) way to find where to point that link to.
- Also, just having a way to do something - for example, checklists in "scratchpad" (whatever that actually is - I have yet to see actual details) - is not enough. We already have a way to deal with those things. And now WMF is offering us something seems to make those things harder. And I don't really see the benefit that would be worth the sacrifice. After all, the current system is not that bad. And yes, I have looked at mw:Flow_Portal/Research/User_Test_Data ([14]). It only shows that WMF should make better user tests. I would also be confused if I had to look for some communication when "my" user name is not familiar to me (and that is just the first problem). The real new users actually tend to find ways to communicate well enough - finding something worth saying tends to be a far more substantial problem (for just some examples, look at [15], [16], [17])... At worst, they are going to write everything in plain text - and that's OK, we can refactor it for them. The same is true for articles as well - which is one of the reasons why "VisualEditor" is not a great success that WMF expected. --Martynas Patasius (talk) 21:00, 21 August 2013 (UTC)
- So, can we expect that in this case the benefits will be at least somewhat comparable with the costs..? --Martynas Patasius (talk) 21:00, 21 August 2013 (UTC)
- Slight correction – we're actually not deploying to user talk in the first release (due precisely to the complexity of some of the requirements you bring up here). I just started drafting up the Minimum Viable Product requirements for the first release on mediawiki.org; I'll copy them over here, too, once the draft is a bit more stable. Maryana (WMF) (talk) 22:23, 21 August 2013 (UTC)
Blocked users
What will blocked users be allowed to do? Appealing blocks is a special workflow, but, if posts are on multiple boards, and the blocked user should be allowed to comment on his own board, if he replies to an existing thread, should his comments be propagated to the other boards that thread is on? Sorry if this is convoluted, but I don't know if it's being considered. — Arthur Rubin (talk) 02:10, 16 August 2013 (UTC)
- Arthur Rubin:Funny you should ask this, as I am literally writing up a functional requirements document that discusses this very topic right now (and similar topics). What you're describing is absolutely being considered. To understand the complexities here, the following must be known:
- Topics have an "owner" Board (the Board it was started on)
- Topics can be attached to multiple Boards
- Flow is inter-wiki, and users may be blocked on some projects but not others
- The current thinking is this: Blocked users will not be able to interact with Topics that are not started on their own Board. If a Topic on their Board is attached to another Board, their replies will show up there. I think this is okay (and probably a good thing, for reasons I'll explain in a moment) because the blocked user is not "forcing" their comments into other Boards; those Boards have, in a way, invited the user to speak there.
- As to why this is a good thing, consider the following (theoretical) "unblock request" scenario:
- Ankit blocks Barbara. The block notice workflow Topic is started on Barbara's board.
- Barbara requests an unblock. The block notice workflow Topic advances its stage, and the Topic becomes attached to a second board, one called, say, "Unblock Requests"
- Admins who subscribe the "Unblock Request" board can now interact with Barbara (asking her questions, etc.) without having to visit her Board directly.
- This clearly gets more complicated when you're dealing with inter-wiki conversations. Barbara is blocked on enwiki but not on commons, and can continue to be involved in discussions on commons. Users who read commons-owned Topics on enwiki will continue to see her posts - but Barbara is not interacting on enwiki; she is interacting on commons.
- I'm not sure if that makes sense. Please let me know.--Jorm (WMF) (talk) 02:35, 16 August 2013 (UTC)
- Multiproject discussions probably aren't worth implementing. There's no reasonable way to manage the interactions of different user-rights on different projects with different rules that span multiple projects. I'd just rip that feature out right now and stop worrying about the problems it causes. We are different projects today, and there's no reason to expect that to stop.—Kww(talk) 03:15, 16 August 2013 (UTC)
- I follow Jorm's statement; I'm not sure it's a good policy. It depends on how a thread becomes attached to multiple boards. — Arthur Rubin (talk) 04:26, 16 August 2013 (UTC)
- Kww, before you reject the idea as not worth it, I want you to think about an RFC that asked editors here a question like, "Commons frequently deletes images without notifying anybody here, where the image is used and where the editor who uploaded it is active, that the image is even being considered for deletion. The WMF says that it is technologically possible to let all interested editors here see and participate in these deletion discussions, without even needing to go over to Commons and login there. Similarly, discussions that happen over at Meta about the WMF's terms of use or privacy policy could be fed straight to users here. Would you like this feature?"
- I'd bet that the response would be very strongly positive to this proposal, even if it means that there are occasional awkward issues with which project's policies apply to which discussion for rarely taken actions (like deletion) . WhatamIdoing (talk) 16:19, 16 August 2013 (UTC)
- I'm sure you could come up with proposals that would be embraced by people that didn't think the issue through. Think through the whole damn mess, though: if English Wikipedia and Commons have two different policies over who can edit comments and an editor active on both Commons and English Wikipedia edits comments in a joint discussion, can he be blocked on English Wikipedia? If there's an interaction ban in place between two editors on English Wikipedia but not on Commons, can they both participate in a joint discussion? Whose policies on personal attacks will apply? We are separate communities with separate policies. This is a feature that is an absolute quagmire with no benefit that couldn't be handled by a simple cross-notification bot. It's also the kind of feature that gets in the way of every design decision because it makes it difficult design the configuration flags necessary to adapt the feature to each individual and unique environment. Flow pages should be restricted to single environments.—Kww(talk) 16:31, 16 August 2013 (UTC)
- I don't believe it's impossible to do this: As Jorm says, the topic is "owned" by a project. The "owning" project's policies should apply to it. So if the topic is "owned" by Commons, then you participate under Commons' policies, which means that if you're blocked or have a topic-ban at Commons, then you don't participate, but if you've got a topic ban from en.wp, then you're free to participate. This is, in other words, exactly like the rules work right now, only with a technological feature that allows you to read Commons' pages without "physically" going over to Commons to do so. It's still a discussion "at" Commons as far as any policy is concerned. WhatamIdoing (talk) 18:00, 16 August 2013 (UTC)
- So if someone wants to evade their restrictions on English Wikipedia, they create the page with Commons ownership and then link English Wikipedia to it? Rendering them immune to sanctions for violating their restrictions on English Wikipedia? No, thanks. It's a bad idea, and should be eliminated from design consideration now.—Kww(talk) 19:45, 16 August 2013 (UTC)
- Unless there were some reason why the discussion needed to involve multiple projects (e.g., deletion of images located at Commons but used elsewhere), then I think that we would legitimately consider that to be a violation of the en.wp ban. Furthermore, I can't imagine why any project would tolerate someone creating off-topic or out-of-scope discussions this way. We'd likely handle that just like we handle the steady stream of people asking the English Wikipedia to punish the admins at some other Wikipedia, i.e., by refusing to have the unrelated project involved in it, and backing up that refusal with blocks and bans when necessary. WhatamIdoing (talk) 20:37, 16 August 2013 (UTC)
- My one thought about this is that this might almost be too much functionality - too many options and it could easily get confusing. It might be worth prioritising core functionalities, and adding functionalities that should, ideally, be minimally used later, after the problems with the core functionalities are worked out.
- If nothing else, a lot of the secondary functionalities probably aren't worth discussing in detail until Flow's core is finished. Once that's done and a few user feedback loops happen, it'll be a lot clearer how such secondary functionalities will be implemented, if they're still on the table (because it's likely some features will later prove to be impractical, or be superseded by some other solution). Adam Cuerden (talk) 08:59, 17 August 2013 (UTC)
- Thinking it over, the idea that the "home board" of a thread determines whether a user (blocked, unconfirmed, etc.) can contribute is a reasonable approach for a prototype. Until the details of how threads get attached to boards is determined, the question of whether it would be workable remains open. — Arthur Rubin (talk) 17:18, 17 August 2013 (UTC)
- Unless there were some reason why the discussion needed to involve multiple projects (e.g., deletion of images located at Commons but used elsewhere), then I think that we would legitimately consider that to be a violation of the en.wp ban. Furthermore, I can't imagine why any project would tolerate someone creating off-topic or out-of-scope discussions this way. We'd likely handle that just like we handle the steady stream of people asking the English Wikipedia to punish the admins at some other Wikipedia, i.e., by refusing to have the unrelated project involved in it, and backing up that refusal with blocks and bans when necessary. WhatamIdoing (talk) 20:37, 16 August 2013 (UTC)
- So if someone wants to evade their restrictions on English Wikipedia, they create the page with Commons ownership and then link English Wikipedia to it? Rendering them immune to sanctions for violating their restrictions on English Wikipedia? No, thanks. It's a bad idea, and should be eliminated from design consideration now.—Kww(talk) 19:45, 16 August 2013 (UTC)
- I don't believe it's impossible to do this: As Jorm says, the topic is "owned" by a project. The "owning" project's policies should apply to it. So if the topic is "owned" by Commons, then you participate under Commons' policies, which means that if you're blocked or have a topic-ban at Commons, then you don't participate, but if you've got a topic ban from en.wp, then you're free to participate. This is, in other words, exactly like the rules work right now, only with a technological feature that allows you to read Commons' pages without "physically" going over to Commons to do so. It's still a discussion "at" Commons as far as any policy is concerned. WhatamIdoing (talk) 18:00, 16 August 2013 (UTC)
- I'm sure you could come up with proposals that would be embraced by people that didn't think the issue through. Think through the whole damn mess, though: if English Wikipedia and Commons have two different policies over who can edit comments and an editor active on both Commons and English Wikipedia edits comments in a joint discussion, can he be blocked on English Wikipedia? If there's an interaction ban in place between two editors on English Wikipedia but not on Commons, can they both participate in a joint discussion? Whose policies on personal attacks will apply? We are separate communities with separate policies. This is a feature that is an absolute quagmire with no benefit that couldn't be handled by a simple cross-notification bot. It's also the kind of feature that gets in the way of every design decision because it makes it difficult design the configuration flags necessary to adapt the feature to each individual and unique environment. Flow pages should be restricted to single environments.—Kww(talk) 16:31, 16 August 2013 (UTC)
- I follow Jorm's statement; I'm not sure it's a good policy. It depends on how a thread becomes attached to multiple boards. — Arthur Rubin (talk) 04:26, 16 August 2013 (UTC)
- Multiproject discussions probably aren't worth implementing. There's no reasonable way to manage the interactions of different user-rights on different projects with different rules that span multiple projects. I'd just rip that feature out right now and stop worrying about the problems it causes. We are different projects today, and there's no reason to expect that to stop.—Kww(talk) 03:15, 16 August 2013 (UTC)
- How does the interwiki stuff work with images? Different projects have different image policies. What happens if I include an image from MediaWiki:Bad image list in an interwiki discussion? Can I see it both when the discussion is viewed on Wikipedia and when it's viewed on Commons? What about WP:NFCC#9 or WP:IUP violations? Also, different projects have different BLP policies. --Stefan2 (talk) 00:57, 27 August 2013 (UTC)
Sugar and spice and everything WP:CIVIL
I was looking at some of the screenshots higher on this talk page, and I noticed that the "click to reply" links conclude with the exhortation to "Be nice!". Before I go any further, please let me be clear: I am in favor of being nice, and I do not oppose niceness, OK? I know that things are still in the development stages, and that a lot of the wording can be configured specifically for each project. I'd like, therefore, to make a suggestion.
A lot of male users in their teens or twenties are, I think, likely to see "nice" as patronizing, and it could boomerang by tempting them to do the opposite. Also, the English Wikipedia does not really assign a role to the word "nice" in policies or guidelines, instead using the word "civil", as in WP:CIVIL. I also recognize that the developers want to make the interface friendly to new users, so I'm not advocating sending users right to wiki-jargon, either.
I suggest changing "Be nice!" to "Please be polite.", with the word "polite" linked to WP:CIVIL, and the exclamation point changed to a simple period. --Tryptofish (talk) 00:09, 22 August 2013 (UTC)
- It won't be possible to include links within that text, btw. It's an HTML attribute called "placeholder"; once you interact with the element (click into it), the text disappears.
- My first thought is that if someone decides to be uncivil because they hate the word "nice" that they're probably going to quickly be blocked for being uncivil. But that's me.--Jorm (WMF) (talk) 00:13, 22 August 2013 (UTC)
- OK, please disregard what I said about the blue link. I actually agree with you about the behavioral part, but I really do think that we do no one any good by tempting them. The word "nice" can come across as kind of prissy to some eyes, and the word "polite" is more adult-sounding. There's so much youthful testosterone on the Internet that I believe it's worthwhile to pay attention to this. I can easily envision users that I come across every day looking at "Be nice!", and thinking, "Who are you, my mother?". --Tryptofish (talk) 00:25, 22 August 2013 (UTC)
- Dear Tryptofish; be nice. :) --Mom 04:50, 22 August 2013
- OK, please disregard what I said about the blue link. I actually agree with you about the behavioral part, but I really do think that we do no one any good by tempting them. The word "nice" can come across as kind of prissy to some eyes, and the word "polite" is more adult-sounding. There's so much youthful testosterone on the Internet that I believe it's worthwhile to pay attention to this. I can easily envision users that I come across every day looking at "Be nice!", and thinking, "Who are you, my mother?". --Tryptofish (talk) 00:25, 22 August 2013 (UTC)
- I don't really feel all that strongly about which word(s), if any, we should use to encourage civility, but I would like to point out that it's very interesting that you assume we should be catering our copy to "male users in their teens or twenties," or that the worst possible thing is to sound "prissy," Tryptofish. There are some deeply-held assumptions and stereotypes packed into those ideas that I think might be good to challenge, even if just hypothetically, as a thought experiment. Because it's absolutely true that much of the text on Wikipedia was written by men for men, and I wonder how much this one simple fact contributes to the ever-present gender gap... Maryana (WMF) (talk) 03:30, 22 August 2013 (UTC)
- Wait a second here. It can be fairly said that Wikipedia is written by more men than women—that research has been done. But "by men for men"? Male I may be, but when I write here, I'm writing for whoever may read it. I haven't seen a "No girls allowed" template at the top of any articles recently. What do you mean by that, when anyone who writes here has no idea who may read it, nor can control that? Seraphimblade Talk to me 21:47, 22 August 2013 (UTC)
- I was just reacting to this from Tryptofish's original comment: A lot of male users in their teens or twenties are, I think, likely to see "nice" as patronizing, and it could boomerang by tempting them to do the opposite. The assumption here appears to be that since most Wikipedia editors are currently male (which we do know from extensive research), we should be writing all our instructional copy (not content; specifically interface and system messages) in a way that makes men think/feel/behave a certain way. What I'm saying is that just because it's factually true that more men edit Wikipedia, we shouldn't necessarily continue to tailor our instructional copy only to them. Perhaps if we broke away from these assumptions about who our users are or could be (like the idea that the word "nice" is too "prissy" for Wikipedia editors and will cause them to intentionally be jerks), we could actually begin to attract a more diverse set of contributors. Maryana (WMF) (talk) 22:56, 22 August 2013 (UTC)
- Wait a second here. It can be fairly said that Wikipedia is written by more men than women—that research has been done. But "by men for men"? Male I may be, but when I write here, I'm writing for whoever may read it. I haven't seen a "No girls allowed" template at the top of any articles recently. What do you mean by that, when anyone who writes here has no idea who may read it, nor can control that? Seraphimblade Talk to me 21:47, 22 August 2013 (UTC)
- I don't really feel all that strongly about which word(s), if any, we should use to encourage civility, but I would like to point out that it's very interesting that you assume we should be catering our copy to "male users in their teens or twenties," or that the worst possible thing is to sound "prissy," Tryptofish. There are some deeply-held assumptions and stereotypes packed into those ideas that I think might be good to challenge, even if just hypothetically, as a thought experiment. Because it's absolutely true that much of the text on Wikipedia was written by men for men, and I wonder how much this one simple fact contributes to the ever-present gender gap... Maryana (WMF) (talk) 03:30, 22 August 2013 (UTC)
- Or we could lose the contributors we actually have without gaining any new ones... It is hard to tell what would happen.
- Anyway, that is beside the point. The actual string of characters is certainly configurable - at the very least because it would have to be translated for other Wikipedias. It is simply unthinkable that things could be done otherwise. Technically, the string itself would have to be a matter of policy - and policy is still decided by the community. And even if WMF would try to overrule the community, such decision is highly unlikely to be done by someone with job title "Product Manager".
- I do think that "Flow", the process of its development and WMF have many significant flaws, but this string is not one of them. --Martynas Patasius (talk) 00:14, 23 August 2013 (UTC)
- Oh, dear, maybe I should repeat what I said to begin with: I am in favor of being nice, and I do not oppose niceness, OK? (And thanks, IP-mom!) Starting a debate about gender was the farthest thing from my mind. (Indeed, anyone who cares might want to look carefully at the user boxes on my user page.) I never said that typical Wikipedians would react the way that I described, but rather that there are a goodly number who would, and that I see some of them every day that I edit. It's not about catering to them, but about being practical in dealing with the way that things are.
- Actually, I'm very much in favor of making Wikipedia more inclusive. But I rather doubt that this particular wording will accomplish that. In fact, another aspect quite distinct from what I said above is that the wording just tends to make it sound like social media, instead of a serious website where an encyclopedia is created.
- It occurs to me that, instead of discussing which word to use, we ought to discuss whether we need to say it at all. Was there any research that led the developers to add the "Be nice!" part to begin with? There is nothing on the current user interface that says that, so is there a reason for introducing it with Flow? --Tryptofish (talk) 00:30, 23 August 2013 (UTC)
- Hey, no worries, Tryptofish – this is just something I'm particularly sensitive to, so I'm a bit of a gadfly about it :) To answer your last question, the copy in the prototype is all super preliminary, not the real deal just yet. You're right that it may not make sense to include any message there at all in the final product; having the same phrase repeated in every single comment box risks an element of banner blindness. We'll play around with it. Maryana (WMF) (talk) 17:06, 23 August 2013 (UTC)
- That's a good kind of gadfly-ery, thanks. My advice would be to seriously consider leaving it out. If you've got to tell someone to be nice, they probably can't be told. --Tryptofish (talk) 00:44, 24 August 2013 (UTC)
- I cannot help thinking of an old maxim about the difference between good girls and nice girls - that it was the good girls you took home to mother, and the nice girls you took to the back alley. So, no, I'd really rather not be told to be nice. Risker (talk) 22:09, 21 September 2013 (UTC)
- Hey, no worries, Tryptofish – this is just something I'm particularly sensitive to, so I'm a bit of a gadfly about it :) To answer your last question, the copy in the prototype is all super preliminary, not the real deal just yet. You're right that it may not make sense to include any message there at all in the final product; having the same phrase repeated in every single comment box risks an element of banner blindness. We'll play around with it. Maryana (WMF) (talk) 17:06, 23 August 2013 (UTC)
What links here and boards (flow)
Will flow be integrated with the rest of wikimedia. Links from flow does they appear in "whats links here"? Christian75 (talk) 08:17, 23 August 2013 (UTC)
What is Flow?
Having encountered the linked term "Flow" in a Portal article (with no explanation), I came here to find out what Flow is. The lede is of no help, saying it is a proposed change and it is not something else. Only after getting well into the article did I get an idea of what Flow is -- sort of. Can some-one please say what it is in the lede, and not just what it is about. For example, "Flow is a proposed change to the talk pages of Wikipedia that would (attempt to) make them easier for novices to use by ...[include the salient characteristic of the changes or deficits to be corrected]." — Preceding unsigned comment added by Kdammers (talk • contribs) 07:18, September 19, 2013 (UTC)
- @ Kdammers check out the main page now and lemme know if that makes a little more sense :) Maryana (WMF) (talk) 17:40, 20 September 2013 (UTC)
- Um, could we have less pro-WMF propaganda and more description there..? For example, "Talk pages—as a discussion technology—are antiquated and user-hostile." ([18]) is simply wrong: isn't WMF far more "user-hostile"..? The same statement is also shown to be false by many users who do manage to express their views even without full understanding of "wikitext".
- So, please, try to write as if it was an article: obey WP:NPOV and WP:V. Fairly describe all significant views, both "pro-WMF" and "anti-WMF". The difference form real article writing is that (perhaps) in this case you can cite yourself as a source of views of WMF.
- There is another advantage in that: if you will force yourself to state the arguments of your opponents fairly and in the way that they will accept themselves, you will be able to understand their position better and even to argue with it more competently (if, of course, you won't get persuaded). --Martynas Patasius (talk) 19:37, 21 September 2013 (UTC)
- I have removed the phrase "user-hostile", and replaced it with "not user-intuitive". Any technology, including Flow, can be used in a user-hostile manner. In fact, I think it's actually going to be far, far easier with flow to be user-hostile, especially given its core philosophies. Frankly, at this stage it looks like facebook - which is already severely outdated technology itself, and is losing users in droves. Risker (talk) 22:04, 21 September 2013 (UTC)
- I'd say it would still be better to write "Wikimedia Foundation [or "Maryana (WMF)"] thinks that talk pages—as a discussion technology—are antiquated and user-hostile, because they use elements of syntax not used elsewhere [or for some other reasons].". And then - "Opponents of this project argue that it is not true, as evidenced by the users who do communicate successfully in the talk pages without mastering the 'wikitext'." (or some different points).
- Although perhaps actually writing this "article" might be better left to Maryana (WMF) (provided that she tries to follow WP:NPOV etc.)..? After all, if her job has anything to do with gathering requirements and persuading us that the project are not worthless and WMF is not our enemy, she needs to demonstrate that she understands the arguments of "anti-WMF" side anyway... --Martynas Patasius (talk) 13:08, 22 September 2013 (UTC)
- This isn't an "article". It isn't subject to NPOV. We are very well aware of the "anti-WMF" arguments (and I have to say that using that name - "anti-WMF" - is not likely to carry any weight with anyone except people who hate the Foundation). Our job is to follow the mission and vision statement of the Wikimedia Foundation. Part of that is to make knowledge sharing available to everyone - not just people who are able to figure out the arcane rules and syntax of talk pages. Talk pages are anti-mission in that regard - they actively work against what we are trying to do.
- If you are not able to see that, I'm not sure if there's a chance of having a productive conversation. If you start your entire premise with "I am anti-WMF", I am not sure there's a chance of having a productive conversation. And if you base everything around "the WMF staff are idiots and don't understand what we're saying and don't get the community", I'm not sure there's a chance of having a productive conversation.--Jorm (WMF) (talk) 18:13, 22 September 2013 (UTC)
- It's starting to appear that we may be having a change of modus operandi that we are not asking for. The present one seems to be more than fit for purpose.
— | Gareth Griffith-Jones | The Welsh Buzzard | — 18:41, 22 September 2013 (UTC)- Gareth, you might want to go look at the very earliest edits by this user on his talk page. If it's "fit for purpose"—and if that purpose is to make things "available to everyone - not just people who are able to figure out the arcane rules and syntax of talk pages", as Jorm put it, then why did this guy have no idea how to post a message (his first-ever talk page words: "Im a new user. Not at all sure how to talk on talk page?? Have been blocked due to not talking...how is this done then please."), and why did he have so much trouble figuring out how to post that message when he needed to? If you hang out at the help desk or the teahouse, this is not actually an unusual level of difficulty. Unless the purpose is to keep new or less technically savvy people away, I can't see how this is fit for the purpose of having discussions with people who aren't already as experienced as you and I are. WhatamIdoing (talk) 23:50, 22 September 2013 (UTC)
- It's starting to appear that we may be having a change of modus operandi that we are not asking for. The present one seems to be more than fit for purpose.
- Sorry, but I am not impressed by your "counterexample"... The same user has been able to find a way to revert an edit ([19]) very soon - on his 10th edit. And using HotCat ([20]) just after the unblock request ([21])... Now it is good to assume that the user is telling the truth, but maybe we could get an example where it would take a little less effort..? And if it has to be an unblock request, maybe it could be without unfair accusations and demands to block directed at one's opponent who has communicated with the blocked user very nicely..? For I don't see why we should go out of our way to keep such newbies... There are enough newbies who are acting much better.
- Also, if the user doesn't notice the posts addressed to him, isn't it a problem with WP:NOTIFICATIONS (that, may I add, is another novelty of WMF)..? How is "Flow" supposed to affect anything about that..? --Martynas Patasius (talk) 01:57, 23 September 2013 (UTC)
- The value in this counterexample is that anyone familiar with this area knows just how typical it is. About 10% of unblock requests are malformed. There's one sitting in CAT:UNBLOCK right now whose editor forgot the closing }}. WhatamIdoing (talk) 02:07, 23 September 2013 (UTC)
- "The value in this counterexample is that anyone familiar with this area knows just how typical it is." - so, it is not addressed to anyone who is not "familiar with this area"..?
- "About 10% of unblock requests are malformed." - and what sample is this "10%" based on..? Anyway, your counterexample shows that "malformed" unblock requests are not necessarily a problem. The unblock request in [22] is malformed, if we'll look formally, but I am sure that the request was not denied ([23]) because it was "malformed", but because it was, well, a bit impolite and had little indication of contrition. And your new "counterexample" is likely to fail for the same reason: if one can find the request and read the valid reason for unblock, no problems with formatting will matter. Contrary to your claims, there are no "arcane rules". It is just that competence (in the sense of being able to communicate in English reasonably and politely) together with humility and obedience are required for all Wikipedians - and they are much harder to learn than "wikitext"... --Martynas Patasius (talk) 02:31, 23 September 2013 (UTC)
- The point you just raised is one that has come up repeatedly on this talk page. In part, I think the WMF folks do themselves no favor when they take the bait from the distinct minority of editors who feel as Martynas Patasius does. Many of us have concerns about effects on consensus-building and so forth, but do not see any of this as us-verus-them. I've become quite won-over to such improvements as automatic signing of comments, automatic fixing of what we now do with indentation, the ability to watchlist just one part of a talk page, and so on. I think that we have to be careful about ways in which the user interface might end up getting altered in ways that mislead new users about how Wikipedians come to decisions, and I am cautiously optimistic that the developers do not want to work at cross purposes with us in that regard. I hope that we are all in this together. --Tryptofish (talk) 19:20, 22 September 2013 (UTC)
- Please do not accuse editors making good-faith inquiries of baiting. That is rude. Thanks. — Scott • talk 11:27, 23 September 2013 (UTC)
- That's what you took away from what I said? It most certainly was not my intention! --Tryptofish (talk) 19:23, 23 September 2013 (UTC)
- Please do not accuse editors making good-faith inquiries of baiting. That is rude. Thanks. — Scott • talk 11:27, 23 September 2013 (UTC)
- The point you just raised is one that has come up repeatedly on this talk page. In part, I think the WMF folks do themselves no favor when they take the bait from the distinct minority of editors who feel as Martynas Patasius does. Many of us have concerns about effects on consensus-building and so forth, but do not see any of this as us-verus-them. I've become quite won-over to such improvements as automatic signing of comments, automatic fixing of what we now do with indentation, the ability to watchlist just one part of a talk page, and so on. I think that we have to be careful about ways in which the user interface might end up getting altered in ways that mislead new users about how Wikipedians come to decisions, and I am cautiously optimistic that the developers do not want to work at cross purposes with us in that regard. I hope that we are all in this together. --Tryptofish (talk) 19:20, 22 September 2013 (UTC)
- "This isn't an "article". It isn't subject to NPOV." - yes, I know. I am saying that it might still be a good idea to write as if it was.
- "Talk pages are anti-mission in that regard - they actively work against what we are trying to do." - well, do you have a proof, or are you just begging the question (assuming what still has to be proved)..?
- "If you are not able to see that, I'm not sure if there's a chance of having a productive conversation." - well, it depends on what counts as "productive". If you only count as productive something that assumes that we do need the "product" ("Flow") then no, it will not be "productive". But I don't see why that is a bad thing. And I also do not see why such a conversation could not be productive in any other way. Well, in principle - I see that you are not really interested in it and it takes at least two sides to have a conversation...
- "We are very well aware of the "anti-WMF" arguments" - good. You might wish to start answering them. "([A]nd I have to say that using that name - "anti-WMF" - is not likely to carry any weight with anyone except people who hate the Foundation)." - it can be "anti-Flow", if you wish.
- "If you start your entire premise with "I am anti-WMF", I am not sure there's a chance of having a productive conversation." - are you sure it is not a conclusion..? Also, how did you understand "anti-WMF"..? I even added quotation marks to emphasise that it was meant to denote a position contrary to position of WMF on the matter of "Flow" (and, perhaps, related projects, like "VisualEditor"). I get the impression that you took it to mean something different... Finally, even real enemies are not unknown to have productive conversations. That is how peace treaties come into being.
- "And if you base everything around "the WMF staff are idiots and don't understand what we're saying and don't get the community", I'm not sure there's a chance of having a productive conversation." - sorry, but that is just a caricature of your opponents' position. Who has called you (or anyone else) an "idiot"..? Who has even implied that..? If someone has, I must have missed it. There is an opinion that you (WMF) might not be doing a very good job, but that is a different thing.
- Or "don't understand what we're saying" - you know that I don't like "Flow" and I know that you know that. To that extent you certainly do understand what I am saying (and that is one of the reasons why I think your description is a caricature of a real position). But statements like "Part of that is to make knowledge sharing available to everyone - not just people who are able to figure out the arcane rules and syntax of talk pages. Talk pages are anti-mission in that regard - they actively work against what we are trying to do." asserted without any evidence do give a reason to suspect that you might not understand the position contrary to yours in full detail... And that is what writing a page as if it had to follow WP:NPOV might help with.
- Now just to show why the assertion about "the arcane rules and syntax of talk pages" is not "self evident", try to think how one can write something on a talk page. Yes: in simple plain text (for example, [24]). One does not need a signature. One does not need to answer with correct indentation. If necessary, someone else can do some refactoring (for example, [25]). Or it can be left as-is. What is "arcane" about that? How are you going to create anything less "arcane"? It would probably require speech recognition... And, unless I am mistaken, "Flow" is not going to have that.
- So, is my position clearer now..? --Martynas Patasius (talk) 23:47, 22 September 2013 (UTC)
- I think your position is crystal clear, and that there's no productive conversation to be had with you about this.--Jorm (WMF) (talk) 00:12, 23 September 2013 (UTC)
- Well, you sure do not seem to be close to persuading or befriending anyone who does not agree with you yet... Then again - I guess that is not your goal... --Martynas Patasius (talk) 01:30, 23 September 2013 (UTC)
- Given the shotgun spray of mischaracterizations and argumentative fallacies that have peppered your replies thus far, Jorm, which Martynas has been able to sidestep with the easy grace of a ballet dancer, no, it does not appear that there is. — Scott • talk 11:27, 23 September 2013 (UTC)
- Comment: I added some info on the guiding principles of the Flow project and Core features development in general. I'm also going to work a bit on fixing up the Rationale section and synthesizing some of the background research. What I'm hearing here is that some people are not convinced that talk pages are one of the "barriers that could preclude people from accessing or contributing to our projects." I'm guessing that's partly due to the fact that the citations to back this statement up are scattered over a number of pages and wikis. If you're still unconvinced even with these citations and feel we should not work on this project, you're welcome to continue leaving us feedback; however, it's unlikely that anyone from the development team will respond, since there's not much to say at that point.
- What we will gladly respond to – and not just with words, but with actual design and development of features – is feedback from anyone who believes that discussion and collaboration can be improved on Wikipedia and offers us ideas, suggestions, even scathing critiques that help keep us working toward our guiding principles. You may not realize this, but if you actually care about improving the discussion system on Wikipedia, you have tremendous power and resources at your fingertips right now – use them :) Maryana (WMF) (talk) 21:02, 23 September 2013 (UTC)