Jump to content

Wikipedia talk:Flow/Archive 3

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4Archive 5→Archive 10

Feature requests

I asked at mw:Talk:Flow Portal for details of a couple of features that are missing from the prototype. I was pointed to repeat the questions here after developers came back from Wikimania, so here they are.

  • What will be the equivalent of the Table of Contents for all comments in the same "owner Board", showing only the titles of each thread and subthread? Will there be arbitrary (up to five) levels of nested subthreads? Will it be possible to filter threads so that only threads up to sub-level X are visible in the overview? All these features are available and quite handy at current talk pages.
  • How will you implement page history? i.e. the log of all changes made to posts in the same owner Board. (This is used among other things to be notified of changes to any post, to search for specific changes made to the conversation by a particular user, and to build diffs of changes as evidence for arbitration). As I understand what I have heard of the proposed system architecture, you're not relying on the current Mediawiki history since each Flow post will count as a separate page. So how do you plan to merge those separate change histories, and is there a way to cache them so that recovering them is efficient? Diego Moya (talk) 06:35, 17 August 2013 (UTC)
  • I would like to add the request that the diffs be really, really easy to create and to understand, and of course unforgable. I volunteer at WP:DRN and we really like diffs so that we know exactly who wrote what and when they wrote it. It is really hard for a new editor to figure out how to create diffs, and even when I do it for them, the often have trouble understanding what they are reading. --Guy Macon (talk) 20:31, 17 August 2013 (UTC)

Mathematics under Flow

I am disturbed by the comment features like math editing are planned for VE, but are not guaranteed to arrive by the time Flow does. It seems extraordinary that editors of mathematics articles will be required to use VE for discussions about mathematics and yet be unable to write the formulae they want to discuss. Is that really intended? Is that not equivalent to telling mathematics editors that their discussions are less worthy of support than others? Is it not a contradiction of this commitment by User:Jimbo Wales that The source editor will remain available so nothing about mathematical editing needs to change at all? Spectral sequence (talk) 19:39, 9 August 2013 (UTC)

I had not thought of that before, but it's a very good point. Discussions about mathematics need to be able to include mathematical markup. --Tryptofish (talk) 00:17, 10 August 2013 (UTC)
Hi. I am πr2, or if you would like to use the math syntax. I added that row to the features table following a discussion above, especially this comment, where math is used as an example. Basically, Jorm said that he doesn't want to promise features in Flow, because it's up to the VE team. The same could apply to the music scores extension for music-editors, or syntax highlighting for programming and CS editors. It's definitely planned, and an important feature, but it seems there's no guarantee. πr2 (t • c) 04:35, 10 August 2013 (UTC)
For a group of editors to be able to discuss the material that might be added to the encyclopaedia is not a "feature", it is a requirement: indeed, effective discussion of how to build the encyclopaedia is the primary purpose of any workflow system. Suggesting that you don't want to promise, or can't guarantee, that we'll be able to discuss our work effectively seems less than adequate, especially since we can with the current system. Why is it proposed to force us to work for some indefinite period without that essential ability? Spectral sequence (talk) 06:23, 10 August 2013 (UTC)
Right now I have the option of using VE or editing the source directly. I was given to understand that nothing about Flow will change this.
This gets back to the basic principle that I have been advocating; It is not the place of the Wikimedia software developers to arbitrarily change any user restrictions or capabilities on Wikipedia without the consensus of the community. An obvious exception is cases where such changes are required by the nature of the software change. Even in those cases, if there are any choices about what new restrictions/capabilities would replace the old, the Wikipedia community should be allowed to make that decision. --Guy Macon (talk) 19:23, 10 August 2013 (UTC)
My question is really rather simple. Is there a design criterion and commitment to implementation of the requirement that editors such as myself, who need to use mathematics for discussion on article and user talk pages, will continue to be able to do so without interruption on the introduction of Flow? Whatever the answer to that question, I would like to see it explicitly stated. Spectral sequence (talk) 19:53, 10 August 2013 (UTC)

In this pdf, Equation support (LaTeX/mw:Extension:Math-based, probably) is listed as "Coming soon". (was mw:User:Jiabao_wu/OPW_Round_6_Application accepted?) @Spectral sequence: The feature request has existed since late 2012, and is "High enhancement" priority. πr2 (t • c) 02:25, 11 August 2013 (UTC)

Thanks for that, but it doesn't really answer my question. The answer to "Is there a commitment to do X at a certain time" is of the form "Yes" or "No", not "There is an aspiration to do X at some time". It is possible to guess from the items you quote that the answer to my question is probably No, but what I'm asking for is that someone in a position to give an authoritative answer do so, and take responsibility for it. Spectral sequence (talk) 06:24, 11 August 2013 (UTC)
I had a helpful discussion with User:Whatamidoing (WMF) at her talk page which addressed some of these issues. Interestingly, she stated that Flow isn't technically my job, or indeed anyone's in any community-facing role. That seems a mistake, given the nature and extent of the concerns articulated here. However, arising from that was what seemed like an important comment.
Technical question. The only thing that has been firmly decided about this issue is that Flow will store its material directly as HTML5+RDFa rather than as (exclusively) wikitext that has to be transformed into HTML every time someone wants to read the page. How will mathematics markup be stored internally, since it is an extension to HTML? It seems necessary to store it in markup form, in order to make it possible to transfer segment of text containing mathematics from articles into discussions and back into articles. What is planned here? Spectral sequence (talk) 17:21, 12 August 2013 (UTC)

I have to admit I find some of the things being said here alarming, although I don't know how seriously to take them. If it becomes impossible to write mathematical notation on talk pages, I would support a blackout of all Wikipedia pages bearing math category tags (maybe 30,000 articles?) until that crime is rectified. Is there some way to bring that about? If not, then maybe simply shutting down Wikipedia until the problem is fixed could be done. I would also feel a moral duty to make the lives of those responsible unpleasant until they fixed the problem. Michael Hardy (talk) 17:43, 18 August 2013 (UTC)

There is a relevant discussion at mw:Thread:Talk:Flow_Portal/Maths where Jorm (WMF) has stated "I cannot promise that there will be mathematics markeup in normal discussion comments. I can promise that there will be collaborative authoring areas in Topics that will accept and store mathematics output." Spectral sequence (talk) 21:26, 18 August 2013 (UTC)

CamelCase and Paternalism

RecentlyTheFollowingArgumentWasMadeOfCourseWhenYou... Oops. Too much time spent reading about CamelCase. Let me try again. :)

Recently,[1] the following argument was made:

"Of course when you poll a group of Wikipedians right now about how they want to deal with all of the bullet points above, they will say they want anyone to be able to edit a talk page comment. That's how they currently deal with those things – just like if you'd asked Wikipedians in 2001 how they want to create internal links in Wikipedia, they would have said 'CamelCase!'"

This got me to thinking; that was a real decision made by real people. It should be possible to see whether anyone wanted to retain the bad CamelCase and reject the then-new square brackets. So I asked at Wikipedia:Help desk#WikiArcheology. I suggest that you stop now and read that discussion.

(Checks email, reads latest on FARK.COM...)Actual Waiting Simulated. Do Not Attempt.

Ah, I see that you are back. Interesting, wasn't it? Perhaps Wikipedians are better at deciding what is best for themselves than we thought... :) --Guy Macon (talk) 03:42, 19 August 2013 (UTC)

Javascript? No way.

Please tell me this isn't Javascript based. I hate javascript pages—they're so slow and clunky, even on a fast computer.—Love, Kelvinsong talk 01:21, 13 August 2013 (UTC)

I don't have any inside knowledge, and Flow is still at an early stage, but everything I have seen so far indicates that the developers working on this are competent and follow best practices. Best practices for web pages include the concept of graceful degradation. See http://james.padolsey.com/javascript/graceful-degradation-still-matters/ and http://www.w3.org/TR/WAI-WEBCONTENT/#gl-new-technologies (checkpoint 6.3) for more details. --Guy Macon (talk) 21:05, 13 August 2013 (UTC)
No, what I mean is that Javascript works for me, and I like to have it in small quantities. However, an infinite scrolling list of Javascript boxes (even a short one) is a recipe for low frame rates, seconds of lag, and a general atmosphere of frustration, even on a fast Linux computer. I'm not enthusiastic about Flow, but if you're going to do it, please keep it at plain HTML and CSS.—Love, Kelvinsong talk 04:06, 14 August 2013 (UTC)
I don't think any of that will happen. the WMF is very much aware that there are still a huge number of users in third-world countries that are still using Pentium II or III processors, 256 or 512 MB of RAM, and 56K modems. Not to mention low-end cellphones or even satellite phones. I fully expect that we will end up with a system that takes full advantage of high-end hardware and fast connections, but will also do all the basics just fine on low-end hardware and slow connections. See http://analytics.blogspot.com/2012/04/global-site-speed-overview-how-fast-are.html --Guy Macon (talk) 06:56, 14 August 2013 (UTC)
I think you'll be pleasantly surprised by the speed we expect Flow to have. Currently, talk pages are monolithic things that must be parsed from wikitext into HTML on every load. Flow doesn't have that problem; Flow discussions will be read (as html) directly out of the cache, and topics will be lazy-loaded as the user scrolls.--Jorm (WMF) (talk) 22:35, 15 August 2013 (UTC)
Perhaps I might repeat my question of 17:21, 12 August 2013 (UTC) which went unanswered at the time. It appears that the only thing that has been firmly decided about Flow is that it will store its material directly as HTML5+RDFa rather than as wikitext that has to be transformed into HTML every time someone wants to read the page. How will mathematics markup be stored internally, since it is not HTML? It seems necessary to store it in markup form, in order to make it possible to transfer segment of text containing mathematics from articles into discussions and back into articles. What is planned here? Spectral sequence (talk) 06:13, 16 August 2013 (UTC)
If Parsoid can figure out how to handle mathematics work in HTML 5, then that's what will happen. The VisualEditor and Parsoid team have their own priorities and I cannot give an estimate as to that timeframe. If Parsoid cannot do this, then mathematics work will have to be done in the scratchpad areas (which will be parsed by the PHP parser).--Jorm (WMF) (talk) 06:43, 16 August 2013 (UTC)
If Flow cannot use mathematical formulas in messages, en.Wikipedia will refuse to use it on article talk pages. (This doesn't prevent implementation, but it does prevent implementation as long as you use the consensual model you've said you are going to use.) — Arthur Rubin (talk) 09:17, 16 August 2013 (UTC)
Thanks to Jorm (WMF) for such a prompt and frank response. It would be interesting to know whether mathematics was simply overlooked in taking that decision, or consciously relegated to the status you describe, but that's not so important right now. What is important is that, as far as I can determine, the requirement to collaborate by copying mathematics over to discussion pages and back into articles is unlikely to be met directly in the near future, and the proposal is to relegate such discussion to a "sandbox". That seems ... sub-optimal. I wonder how mathematics editors are expected to feel about that? Spectral sequence (talk) 16:53, 16 August 2013 (UTC)
Nono, not a "sandbox", he really did mean a "scratchpad", by which he refers to discussions at mw:Subpage scratchpads? and elsewhere. It's a completely different beast from a sandbox - it will hypothetically be embedded in a discussion thread, somewhat like a post-it-note at the side, if that helps clarify it for you. It will be integral to the discussion, and edited in the same place, just using a different subsystem to parse it. (or something). –Quiddity (talk) 18:23, 16 August 2013 (UTC)
I see. So will it (hypothetically) support copy-and-paste or some other equally convenient way of transferring mathematics from articles to discussions and back? And will we (hypothetically) be able to edit the mathematics markup directly? If so, then the new system will be only marginally less convenient (for this purpose) than what we have already. Spectral sequence (talk) 18:30, 16 August 2013 (UTC)
The VE math extension is being worked on at mw:User:Jiabao wu/GSoC 2013 Project Work, and it was testable a few weeks ago at mw:VisualEditor:TestMath (although it seems to be hanging, at the moment). But mw:User:Jiabao wu/GSoC 2013 Project Work/Math Node User Interface seems to be appreciating your comments. So, I would guess that VE will directly support math examples in the near future, and if it doesn't, then the devs know that the fallback editor will need to handle it, well before Flow is deployed to any pages that ever see users needing it (See the moments-ago Timeline update). I'd assume (based on everything I've read) that there is a 0% chance that Flow will arrive at usertalkpages or wikiproject mathematics pages, until <math> is handled in a comparably easy way to how it is currently used. –Quiddity (talk) 19:38, 16 August 2013 (UTC)
How VE handles mathematics and how mathematics is stored in the Flow database are different issues. I would like to believe that you are correct, but to be honest, I would rather we did not "guess" or "assume" things here. Spectral sequence (talk) 20:08, 16 August 2013 (UTC)
Additional. I have been told "The fact is that no decision has actually been made with regard to data storage yet. I know this for a fact because I'm the one whose job it is to decide those things. There is a strong leaning toward HTML5+RDFa from folks in the design and development team, and right now they're prototyping features on a local mediawiki instance with the assumption that we'll have HTML5+RDFa storage, but that doesn't mean things can't change before we write any production code – which nobody has done yet." [2] It would be good to have that promulgated here, so that engagement between contributors and developers (on this board or at some other venue?) could be about what are the possible modes of storing and rendering text with specialist markup, such as mathematics, and what is the best choice to make. I suggest that the ability to transfer material from articles to discussions and back is essential, that it is very important that the transfer be as easy as possible, and that it is highly desirable that it should render the same on all pages (there are regular discussions about how to mark up a tricky piece of mathematics so that it renders well on a variety of browsers and platforms). Presumably there is some date by which that decisions will need to be taken and knowing that would help to structure the engagement. Spectral sequence (talk) 08:04, 17 August 2013 (UTC)
So, I just had a conversation with the lead developer of Parsoid, and he says that support for savinga and rendering <math> via Parsoid (as HTML5/RDF) is already done - there's just no VisualEditor hook for it, which doesn't impact Flow at all. So maybe we can stop worrying about this.--Jorm (WMF) (talk) 18:31, 19 August 2013 (UTC)
Well, can stop worrying about it for Flow, anyway. Sounds like a good complaint to redirect to the VE team. Adam Cuerden (talk) 18:38, 19 August 2013 (UTC)
Excuse me, the use case was "the requirement to collaborate by copying mathematics over to discussion pages and back into articles". Can you now confirm that this will be possible under Flow? Spectral sequence (talk) 18:48, 19 August 2013 (UTC)
I literally just watched someone do that with our internal builds. So yes. Can we drop this now?--Jorm (WMF) (talk) 19:02, 19 August 2013 (UTC)
Thank you for clarifying that. Spectral sequence (talk) 19:39, 19 August 2013 (UTC)

Scrolling and lazy-loading

Sorry, Jorm, you said things are Lazy-loaded as the user scrolls. Doesn't that screw over any attempts to use browser-based find tools (usually Ctrl-F)? Will there be an alternate functionality if you can't just wait for the page to load? Adam Cuerden (talk) 05:48, 17 August 2013 (UTC)

There's a bigger generic question: how will I be able to search Flow pages at all? If I want to search for an individual statement by an individual editor, but don't know precisely what page it was made on, how can I find it?—Kww(talk) 06:04, 17 August 2013 (UTC)
Well, first, to Kww, you may want to actually spend some time with the prototype, as your answer lies with the search tool that's there.
To Adam, the answer is "yes and no". Lazy-loading of content is done with loading-by-page in what is called a "promise". The first set of items (page) - say 20 Topics - are loaded immediately, and the next 20 are loaded after the user scrolls to, say, item 10. Browser-local search functions (Ctrl-F) will only work for the items that are loaded into the browser (as is the case with all sites that have this functionality) (so yes, that gets broken).
However, Flow gets around that by having a persistent, always available search tool. I think (hope) that you'll be pleased with the way it behaves and how it functions.--Jorm (WMF) (talk) 06:11, 17 August 2013 (UTC)
Is there any way to make Flow's tool override Ctrl-F? Because, if so, the issue becomes minimal. Adam Cuerden (talk) 06:13, 17 August 2013 (UTC)
Interesting idea. I'm not sure if we can program accelerator keys that will override browser defaults. I'll see if that's possible.--Jorm (WMF) (talk) 06:14, 17 August 2013 (UTC)
I wouldn't like a script at any one website overriding the default behavior of my browser, which is expected to work in a consistent way every time. I don't think it can be done, but if it can, please don't do it; it's a bad idea (sorry Adam). Find a different accelerator key and put a visible widget on screen for the different search behavior. Diego Moya (talk) 06:59, 17 August 2013 (UTC)
Jorm, the search box on the prototype doesn't do anything, and it isn't clear from its location whether it searches all boards or just the one I am currently looking at. Is there a way to specify a range of boards to do the search on, similar to the prefix based search that's available for talk pages today?—Kww(talk) 06:23, 17 August 2013 (UTC)
That's. . . odd. The search is actually fully functional; are you using Chrome or Firefox?--Jorm (WMF) (talk) 06:26, 17 August 2013 (UTC)
OK, I can see what had happened. I was on a page, and searched for a piece of text that occurred only on that page. You displayed searching graphic, and then displayed the page. You didn't highlight the searched-for text in any way, so I didn't realize that anything had happened at all. When I back out and do a search that occurs in multiple pages, you do display the messages the string occurs in, but once again with no highlighting of the searched-for text. So, how do I do the equivalent of a prefix search? And would you please highlight the searched-for text in the results?—Kww(talk) 06:36, 17 August 2013 (UTC)
Yeah, we should be doing search highlighting. However, the prototype doesn't support it because it's a prototype. I spent about half an hour trying to fake it up and gave up. Search will be context-local (you'll be searching the local Board or Feed, not all Boards. For global search you'll have to use the main search system, but that may not be something that is a launch feature (as goofing with the global search is a pretty tall order and requires resources from outside of the E2 team.)--Jorm (WMF) (talk) 06:51, 17 August 2013 (UTC)
I think you should consider this a must-have feature for anything outside of a sandbox-style test.—Kww(talk) 06:55, 17 August 2013 (UTC)
Hmm. That brings a slightly awkward problem: if the page has, say, 200 posts, we're going to need a way to scroll the page directly to the first instance, then second instance, etc; otherwise, large talk pages will become unusable. Adam Cuerden (talk) 06:44, 17 August 2013 (UTC)
Well, the "search" is actually more like a "filter". If a Board has 2000 items, and the search term returns 200 hits, only those 200 items appear on the page while the filter is active. This is actually how the prototype works (I managed to get that part working).--Jorm (WMF) (talk) 06:51, 17 August 2013 (UTC)
By "item" here, do you mean a single post or a whole thread? I'm searching for "regards" and only two posts contain the word, but six posts are displayed. Is this the expected behavior? Diego Moya (talk) 07:09, 17 August 2013 (UTC)
By "item" I mean whole Topic. There's no point in showing you singular comments without context.--Jorm (WMF) (talk) 07:14, 17 August 2013 (UTC)
Well, the problem is that doesn't solve the ctrl-F problem. If a thread has 200 posts, and you want to find one in it, the lazy loading will prevent you from doing so unless there's a method coded. I don't imagine it'd be particularly hard coding, just something to make sure to do. =) Adam Cuerden (talk) 07:16, 17 August 2013 (UTC)
Can your software show just the comments containing the searched content, and provide a "parent" link that will expand the topic on demand? This way users can find what they're looking for, and context is still available but only when needed. This is how common forum software implements search, so there's a chance that it's not a bad solution. (Totally unrelated question: do you have an interaction designer -someone related to UX-, or are the inmates running the asylum?) Diego Moya (talk) 07:51, 17 August 2013 (UTC)
Prototype. Not final product. Unlikely to be further expanded, as development has begun. Not easy to do rapid iteration of interaction design in code. I've got 20 years as a designer; I know where the interaction is buttered.--Jorm (WMF) (talk) 07:58, 17 August 2013 (UTC)
As I said, it's something to keep in mind; it may not be first priority, but it'll be needed when it's fully launched. Adam Cuerden (talk) 08:46, 17 August 2013 (UTC)
(edit conflict)Ok, glad to hear that. I didn't mean to implement that on the prototype, but as the model for the final product. If you'll do iteration with users where interaction is buttered, that should fix interactions that are problematic. Diego Moya (talk) 08:48, 17 August 2013 (UTC)

You may be interested in this, which is a work in progress but hopes to address some things brought up here.--Jorm (WMF) (talk) 00:33, 19 August 2013 (UTC)

That looks very useful, and most likely will deal with the issue. Thanks, Jorm! Adam Cuerden (talk) 19:55, 19 August 2013 (UTC)

"Is it time for mathematicians to leave Wikipedia?"

This discussion at Wikipedia talk:WikiProject Mathematics is about "Flow". That is the liveliest and most successful of all subject-matter-defined WikiProjects. Michael Hardy (talk) 17:45, 18 August 2013 (UTC)

I hope that no one is going to leave. And I truly believe that everyone at WMF sincerely hopes the same thing that I do. --Tryptofish (talk) 17:53, 18 August 2013 (UTC)
I started that discussion, and it's wider than just Flow, it's about what the editing process will look like after both VE and Flow, and the associated changes, arrive. We are now at a point where for certain groups of contributors, merely "hoping" that things will turn out well are simply not enough. We as contributors need to decide whether or not it is worth engaging with the design and build processes. And to make that decision we need WMF to articulate clear plans, clear priorities and a clear and effective process for user engagement. Spectral sequence (talk) 18:11, 18 August 2013 (UTC)
Michael, it is likely that MILHIST will disagree with your characterization. WT:MATH is only 13th for non-bot edits to the projectspace and 2nd place for the number of active users watching the talk page. WhatamIdoing (talk) 20:32, 19 August 2013 (UTC)

Request for Comment on editing other user's comments with Flow

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The result of this discussion was an overwhelming consensus: 28 users supported letting anyone edit another person's talk page comments, 9 users supported letting any autoconfirmed user edit another person's talk page comments, and 0 users supported limiting this to reviewers, rollbackers or administrators. In addition, one user made a proposal that concerned user talk pages; this RfC applies to article talk pages only. --Guy Macon (talk) 18:46, 10 August 2013 (UTC)

Background: Wikipedia:Flow is a planned improvement to MediaWiki talk pages. As with any major software change, some things that used to be difficult or impossible will become easy, and some things that used to be easy will become difficult or impossible. This is the nature of software upgrades and is specifically not part of this RfC.

This RfC is about a proposed policy change which has been bundled with the technical changes: Who will be allowed to edit another person's article talk page comments? Clearly there is no technical reason that forces a particular answer to that question; it could be anyone, autoconfirmed users only, administrators only, bureaucrats only, nobody, or even a newly-created user group.

When thinking about the question of who will be allowed to edit another person's article talk page comments, please don't make the mistake of only considering some kinds of talk page comments. The policy must be able to deal with every situation: a vandal who doesn't like a well-thought-out comment from an established user, a vandal-fighter who is cleaning up after a spammer who hit hundreds of pages, two edit warriors who have decided to go after each other with guns blazing, and all of the other examples found in WP:TPOC.

Another aspect to consider is workload. The English Wikipedia has 48,309,668 registered users, 122,731 active editors and 851 administrators. Any time you take work away from ordinary editors and give it to administrators, you need to ask whether they will be able and willing to shoulder the extra load.

Please note that administrators have all the powers of rollbackers, rollbackers of reviewers, reviewers of autoconfirmed, and autoconfirmed of unregistered. Thus you only have to support the lowest level that is acceptable to you; you don't have to explicitly support reviewers or administrators if you support autoconfirmed users. That's a given. --Guy Macon (talk) 12:45, 28 June 2013 (UTC)

Survey: who should be allowed to edit another person's article talk page comments?

Use: # '''Support:''' (Reason) --~~~~

Support all users

This includes IP Users (see Wikipedia:User access levels#Unregistered users). This is what we allow now.

  1. Support: I see no reason to change existing policy from a social standpoint merely because of a technical change. We can deal with abuses the same way we do now. No need to fix something that isn't broken here, and if Flow allows it technically, then I see no reason to not allow it. --Jayron32 15:33, 28 June 2013 (UTC)
  2. Support: No reason given to change. Edgepedia (talk) 17:07, 28 June 2013 (UTC)
  3. Support. If we don't let IPs edit talk page comments, we might as well not let them edit at all. Treating IP editors like other editors is a well-established principle here, and not allowing them to refactor talk page comments is essentially denying that they can become established, trusted users, even if it may let in vandalism. Also per above. Cathfolant 17:23, 28 June 2013 (UTC)
  4. Support Yes, you shouldn't normally edit other people's comments, but exceptions always happen, and as Cathfolant says, this would place additional barriers (of which too many already exist) between registered and nonregistered people. The existing system is substantially better than this coming Facebook-style setup; since WMF are forcing it on us, we'd better do our best to blunt its changes by retaining as much as we can. Nyttend (talk) 21:04, 28 June 2013 (UTC)
  5. Support. Note that WP:NPA states that "Derogatory comments about other contributors may be removed by any editor." --Apteva (talk) 00:12, 29 June 2013 (UTC)
  6. Support There is no reason to pre-emptively deny permission for something so basic just because a new software feature would allow us to do so, and there is certainly no reason an admin should be required to remove talk page vandalism or trolling, and of course I very strongly support the idea that users be allowed to remove anything they like from their own talk page. Beeblebrox (talk) 01:06, 29 June 2013 (UTC)
  7. Second choice per Nyttend, the first being the consignment of this project to landfill. MER-C 03:04, 29 June 2013 (UTC)
  8. Support - per all above, it's doubtful we would want to change a core principal of Wikipedia. Mlpearc (powwow) 03:18, 29 June 2013 (UTC)
    • Is "Make sure that all users have the ability to add the word not to your personal signed comments (or remove it)" actually a core principle of Wikipedia? Is it actually a core principle that someone be able to remove your "support" comment and replace it with a "Letting people change other people's comments is stupid" comment that appears (to anyone not searching through the diffs) that you personally oppose this? WhatamIdoing (talk) 09:49, 30 June 2013 (UTC)
  9. Support - Yes. Editing by all has never been a problem, it there is no significant advantage to changing it. Legoktm (talk) 21:50, 29 June 2013 (UTC)
  10. Support. I've waited a while to decide since when I first saw the RfC, because I really had to think about it. After all, we're talking about who can do something that usually should not be done anyway. And if I'm reading the table on this page correctly, the current plan is to limit it to administrators, which strikes me as a lousy thing to inflict on administrators. In the status quo, anyone can change someone else's edit on an unprotected talk page, and anyone else can revert that change. Unless reverting is going to get a lot more difficult under Flow (will it?), I don't see that much need to change this aspect of policy along with changing the interface. But I've taken very seriously the arguments made for autoconfirmed, and I agree that it's going to be an increasing problem to deal with vandalism and general stupidity, so we may end up eventually having to put restrictions on non-autoconfirmed users after all. And I'm someone who has one of those "registration should be required to edit" user boxes on my page, even though I generally get along just fine with IPs and I'm not really convinced that we should actually do what the user box endorses (go figure). But I'd like to try starting out without those restrictions. --Tryptofish (talk) 22:23, 29 June 2013 (UTC)
  11. Support - IPs are human too! I agree with most of what was said above. Talk page comment refactoring isn't a common form of vandalism, and I see no reason why we can't continue the existing policy. Michaelzeng7 (talk) 01:36, 1 July 2013 (UTC)
  12. Support Don't see any reason why we should change this. Armbrust The Homunculus 18:35, 1 July 2013 (UTC)
  13. Support. The current setup works well, and comment-vandalism is extremely rare. -- Ypnypn (talk) 02:47, 2 July 2013 (UTC)
  14. Support. If it ain't baroque, don't fix it. rʨanaɢ (talk) 11:55, 2 July 2013 (UTC)
  15. Support I agree that no change from traditional practice is warranted at this point. If it turns out to be demonstrably problematic on a large scale in the future, this may be considered again. Though we can anticipate that problems are likely to arise punctually on some active talk pages (e.g. Talk:Barack Obama), the proper way to handle that is by providing a form of page protection by which admins can restrict other users' comment editability. Cenarium (talk) 21:11, 5 July 2013 (UTC)
  16. Support I don't think the status quo is broken, so I don't want to "fix" it. --BDD (talk) 16:52, 8 July 2013 (UTC)
  17. Support. It's a wiki. --Yair rand (talk) 06:01, 9 July 2013 (UTC)
  18. Support There are as many problems with IPs editing talk page messages than there are articles, where most are contributive, and User talk pages are not seen often by vandals who go to more-read articles. ~~Ebe123~~ → report 19:27, 13 July 2013 (UTC)
  19. Support. This is absolutely necessary, and there is no good reason to change it. What I'm simply astonished by is that anyone thinks it's a good idea for a software change to redefine what kind of edits are possible, and it doesn't seem that those driving or cheerleading these changes are familiar enough with how Wikipedia actually operates (i.e., how we editors operate it) to know what is or isn't necessary. Providing an alternative method of editing talk pages is fine, but the tail shouldn't wag the dog. Software changes should further empower editors, not hamstring them. postdlf (talk) 16:32, 15 July 2013 (UTC)
  20. Support - IPs are people and it's a wiki. NorthBySouthBaranof (talk) 08:32, 16 July 2013 (UTC)
  21. Support - naturally. This is the wiki way, and it is a valuable and scalable idea. Current practice on talk pages is fine. – SJ + 19:41, 16 July 2013 (UTC)
  22. Support. No need to change the status quo. A412 (Talk • C) 23:03, 18 July 2013 (UTC)
  23. Support - Nothing wrong with current policy. -- TOW  talk  02:09, 22 July 2013 (UTC)
  24. Support - Current system works fine, no demand for the "feature" of limiting editability. Unilateral implementation of this change will start a shitstorm, trust me. Carrite (talk) 03:17, 22 July 2013 (UTC)
  25. Support, this is not a significant problem at this time, and if it becomes one in a specific place or from a specific editor, we can block or semiprotect as we do today. Seraphimblade Talk to me 02:41, 23 July 2013 (UTC)
  26. Support If it aint broke, don't fix it. This is the simplest solution, and provides the most flexibility to editors. Monty845 02:20, 27 July 2013 (UTC)
  27. Support There is no need to change it. Unnecessary change and restrictions should be avoided. Ramaksoud2000 (Talk to me) 20:16, 3 August 2013 (UTC)
  28. Support - I see no reason to change this. TCN7JM 09:47, 6 August 2013 (UTC)

Support autoconfirmed users

(See Wikipedia:User access levels#Autoconfirmed users).
These are the editors who can edit semi-protected pages. We have 48,309,668 autoconfirmed users, 122,731 of whom are active editors.

  1. Support: This one seems most appropriate. In the current setup, even IPs and new accounts can edit others' TP comments, so restricting the ability to confirmed users may eliminate a bit of vandalism. I've most often edited TP comments to remove e-mail addresses or other contact information, and it would be a pain for a regular user to have to contact a rollbacker or reviewer in such instances. In my experience, any users who improperly edit others' comments are quickly reverted, and I'm sure it will be the same with Flow. --Deor (talk) 13:59, 28 June 2013 (UTC)
  2. Support. I want the first person who spots it to be able to remove template vandalism or inappropriate/harmful urls or spam. Spam, in particular, is starting to take over smaller projects, and will only get worse here as our RC patrol corps dwindles. As well, I think users should be able to manage what is and is not on their own board, including having the right to remove or alter messages that they feel are inappropriate. Risker (talk) 06:28, 29 June 2013 (UTC)
  3. Support. Risker's argument above convinced me to change my support from "reviewer" to "autoconfirmed". I carefully read the arguments above supporting "all users" and my conclusion is that autoconfirmed is a better choice. IP users would still be able to revert article vandalism, which is where at least 95% of the vandalism happens. Except in certain well-defined cases, our policy already forbids editing another editor's signed comment, and it is not reasonable to expect a new IP editor to know what those well-defined cases are. --Guy Macon (talk) 17:33, 29 June 2013 (UTC)
  4. Support - on consideration, I think there's good reason to limit IPs from being able to edit other users' comments. I wouldn't go any further, though: in general, this is an option that should be available to all users when necessary. But it seems reasonable to keep it from the newest users, who will be less aware of when editing other users' comments is appropriate and more inclined to vandalise them. Robofish (talk) 21:01, 30 June 2013 (UTC)
  5. Support. I've fixed (and seen fixed) many old instances, of IP-users deleting/mangling/altering the comments of other editors (Similar to WhatamIdoing's examples above. Or this example from yesterday, where I had to search through a lot of diffs, to determine who had deleted what, and when.). It's rare that an IP-user fixes the comments of another editor (It definitely occurs, but it's rare proportionally). –Quiddity (talk) 22:39, 30 June 2013 (UTC)
  6. Support. With this new system in place, I think a minor restriction like this just naturally comes with the territory. In particular with its user-friendliness and similarity to other web forums it can be argued that unhelpful IP editing and trolling of other users' comments would actually increase once they notice that they "can actually do that here". -- Ϫ 02:10, 1 July 2013 (UTC)
  7. Support I've seen too much mangling of talk page comments by IP users. If something needs prompt action on a talk page, one of the 100,000 plus active autoconfirmed users can handle it. Edison (talk) 19:51, 11 July 2013 (UTC)
  8. Support as long as everyone has the right to edit comments left on their own talk pages. I think this will eliminate most editing of others comments and allow tracking of what remains. The exception for your own user talk page is so that everybody can remove any harrasment, etc. from their own talk page in the way they currently can. Thryduulf (talk) 11:14, 15 July 2013 (UTC)
  9. Support Autoconfirmed only. These are people who have shown enough interest in improving Wikipedia so they've taken the step of truly "joining the community." GeorgeLouis (talk) 07:21, 22 July 2013 (UTC)

Support reviewers

(See Wikipedia:User access levels#Reviewer). You become a reviewer by asking an administrator to make you one, and any administrator can revoke the permission. These are the editors who who are able to review other users' edits to articles placed under pending changes protection. We have 8,874 reviewers.

  1. Support: The level of trust needed to review pending changes is roughly equivalent to the level of trust needed to edit another user's talk page comments. This and rollbacker are the user rights on this list that are most easily revoked if they are abused. --Guy Macon (talk) 12:21, 28 June 2013 (UTC) Note: Risker's argument above convinced me to change my support to autoconfirmed. --Guy Macon (talk) 17:19, 29 June 2013 (UTC)


Support rollbackers

(See Wikipedia:User access levels#Rollback). You become a rollbacker by asking an administrator to make you one, and any administrator can revoke the permission. These are the editors who who are able to "roll back" several changes at once instead of one at a time. We have 7,709 rollbackers.

  1. Support: (Reason) --~~~~


Support administrators

(See Wikipedia:User access levels#Administrators). You become an administrator through the requests for adminship process. We have 851 administrators.

  1. Support: (Reason) --~~~~


Support another user group not listed

Note: if you want to create a new user group, please explain in detail why none of the current user groups are suitable.

  1. If a user group other than "all users" is selected, then I propose that everybody be allowed to edit others comments on their own user talk page. There are reasons to restrict editing of others comments on article talk, etc, but everyone should have the ability to remove hurtful/insulting/trolling/etc comments from their own user talk page as they currently can. The only exception is blocked editors who have been blocked from editing their talk page, who should obviously not be ale to alter others' comments on it. Support as proposer Thryduulf (talk) 11:20, 15 July 2013 (UTC)


Threaded discussion

Please respond here rather than inserting a threaded discussion into one of the support lists.


  • For starters, i would like a bit more clarity on what exactly we are talking about here. Currently anyone can edit another person's comments, but in most cases they shouldn't. Are we talking about technically restricting the ability to edit other people's comments or just a rule change? It's not clear from what I am seeing here so far. You also mention workload. What workload is there that is generated by the ability (need?) to edit other people's talk comments? That's totally unclear to me. Would this mean that only users in this new restricted group could archive user talk pages? Beeblebrox (talk) 14:32, 28 June 2013 (UTC)
  • We are talking about the software not allowing certain people to edit other people's comments, and the question is who. Flow will make many things that are now policies or guidelines moot. For example, if I don't sign this, you might point out that I should, template me, etc. Once Flow is running, it will be impossible for me to not sign my comment.
The workload issue is this: Right now, if I see that someone has posted !!!PIGGERS ARE AWESOME!!! !!!GO PIGGERS!!! I can click my handy rollback-vandal button and it instantly goes away and the user's talk page opens so I can drop a template there. If Flow takes that ability away from me, I will have to ask you and you will have to do a bit of extra work (or maybe a lot if Flow makes it cumbersome for you). There are 85 active editors for every administrator, so you might have to spend a fair amount of time doing things like that for me and 84 of my close personal friends. And that's assuming that every administrator pitches in equally. --Guy Macon (talk) 15:48, 28 June 2013 (UTC)
Re: "Would this mean that only users in this new restricted group could archive user talk pages?" as far as I can tell (details are sparse) manually archiving will be as impossible -- for everyone from a new IP editor to Jimbo -- as not signing your posts will be, because the entire concept of archiving will be gone. WP:FLOW says "No need to archive discussions—old posts will automatically 'fall off' the page, and can be retrieved by scrolling down or searching for them.". --Guy Macon (talk) 16:08, 28 June 2013 (UTC)
Thanks for clarifying all that. Beeblebrox (talk) 01:08, 29 June 2013 (UTC)
I think it would be a mistake to not make a readily accessible automatic archiving system whose speed could be configured per talk page, since users may be tempted to comment in old discussions, manually 'hatting' threads as proposed would be too time consuming. A further issue is that we often 'deactivate' talk pages which are no longer in use and put their archives in the archives of another talk page (e.g. WT:PC). Cenarium (talk) 19:53, 28 June 2013 (UTC)
I guess we'd have to set an upper limit for automatic archiving, for example 3 months (configurable in mediawiki space), valid for all pages, with the possibility for, for the sake of argument, autoconfirmed users, to set a quicker automatic archiving period on a given talk page, to manually archive threads (which would be different from hatting, since hatting would let recent discussions visible until archived), and unarchive threads. Then we would need a way to deactivate a talk page and link the archives of this talk page from abroad. Cenarium (talk) 19:58, 28 June 2013 (UTC)
You may wish to familiarize yourself with the actual documentation describing the way that archiving works before commenting on it.--Jorm (WMF) (talk) 20:08, 28 June 2013 (UTC)
I did, and I maintain that not allowing a quicker archiving period to be configurable on specific talk pages, would make the system unwieldy. On very active talk pages, the archiving speed can be set as fast as every 36 hours. We need a system that can handle both quick archiving and easy access to archives, even recent ones. One of the reason liquid threads failed is that it couldn't handle very active talk pages. I'm unsure as to the meaning of "based on the type of discussion" but it doesn't seem to mean per talk page to me. Being able to deactivate talk pages, redirecting them to others and linking their archives is also important, I don't see it addressed, a way to do that would be by allowing admins to move threads to another talk page. I'm aware this is in development, and this only concerns user talk in first release, though some user talk pages are also highly active (jimbo for example), those are just preliminary suggestions. Cenarium (talk) 20:38, 28 June 2013 (UTC)
Why wouldn't archiving just work by line count instead of time based archiving? It seems that a huge wall of text is what we want to avoid and line count would be better than straight time. I believe the archival systems already allow that option. 174.118.153.129 (talk) 02:57, 29 June 2013 (UTC)
Isn't it premature to talk about required policy changes due a technology/extension that hasn't had a line of code written for it yet? YuviPanda (talk) 16:45, 28 June 2013 (UTC)
@Cenarium:: is it that you want topics to be shuffled off into the Great Unreadable Void sooner, or that you want people to stop responding to them sooner? The first seems anti-constructive to me; the second is clearly solvable in software by adjusting the "time to stale" element on a topic. But this assumes that a single page "owns" a topic in Flow, and that's just not the case at all. Topics are self-owned entities. They may have multiple "associations" - multiple Boards wherein they appear - but that doesn't mean that the exist in only one location.
Consider a hypothetical future where a vibrant, fully fleshed AFD workflow exists. A topic about an article's deletion could appear in multiple places: a list of AFDs, the Board of the nominator, the Board of the person who created the article, the article itself, etc., etc. Each of these may choose to have different "stale" and "close" times. Which takes precedence?--Jorm (WMF) (talk) 01:38, 1 July 2013 (UTC)
(EC)Isn't it a bit premature to hire an architect to design a house before one nail is driven? Not capturing Software requirements before coding is a classic rookie mistake. Read about it at Software development process and Requirements engineering. --Guy Macon (talk) 17:04, 28 June 2013 (UTC)
I don't think Yuvi needs a primer on software development and I think that referring to the development team as "rookies" is rude. Feel free to be rude to me, but not other members of the staff.--Jorm (WMF) (talk) 20:08, 28 June 2013 (UTC)
And how was I to know that he was a member of the staff? Nothing in his question or signature indicates that. Do I now have to check the home page of everyone who asks a question on an RfC on the off-chance that they might be a staff member? Now that I do know, I am at a loss as to why he appeared to advocate coding before capturing requirements. He couldn't possibly have meant that (I am sure that he has read The Mythical Man-Month just like everyone else working in software development) and thus I can only assume that somehow I have somehow completely failed to parse his actual meaning. --Guy Macon (talk) 22:42, 28 June 2013 (UTC)
Not commenting as a staff member (and in this case IMO irrelevant, since I've nothing to do with Flow). Ignoring the attempts to 'school' me, with articles of currently dubious quality(Requirements engineering) - can you tell me why this should be dealt with right now, as an RFC for a particular solution ('who can edit whose posts') - rather than as discussions about the underlying problems (which, from my reading, primarily seems to be 'vandals!') and their potential solutions? YuviPanda (talk) 13:50, 29 June 2013 (UTC)
You gave no indication that you were anything other than what you appeared to be from your post -- someone who knows nothing about software development. Thus my "schooling" you by pointing you to the Wikipedia page on the topic that you gave every appearance of being ignorant of was entirely appropriate given the information I had at the time. If you wish to be treated specially because you are a software developer or WMF staff member, you need to mention that fact. I cannot read your mind and it is unreasonable to expect me to read the user page of everyone who asks a question before I reply. I advise that you and Jorm drop the WP:STICK. I did nothing wrong.
As for "why this should be dealt with right now" That has been dealt with in detail in another section. Do a search on "What functionality, exactly, will I be losing here" and you will be at the top of the relevant discussion. --Guy Macon (talk) 21:34, 30 June 2013 (UTC)
And how was I to know that he was a member of the staff? - my next question would be why you feel it is okay to be rude to anyone, let alone staff members? I would encourage you to assume good faith - not just about intent, but also skill level and mastery of technique. Posting links to articles does not make you an expert in using them.
Additionally, it seems to me that you are railing about us engaging in the process that you are advocating - that is, attempting to determine user scenarios and needs before implementation. If you feel that this system is failing, I'm willing to work to make it better. However, I am not willing to stand by while a colleague is attacked simply for asking a question, especially since it was me who pointed out that Yuvi was staff, not him (and he would have been perfectly happy not to have that come up, I should think).--Jorm (WMF) (talk) 01:33, 1 July 2013 (UTC)
I WAS NOT RUDE. Your repeating that claim does not make it true. You are making a false accusation. And you are doing it publicly and against someone who chooses to post under his real name and thus has a real-world reputation to defend. Yes, that was my choice and does not mean that I should get any sort of special treatment, but common courtesy also has a place on Wikipedia.
Furthermore, you appear to have badly misinterpreted WP:AGF, claiming that It is, in your words, "not just about intent, but also skill level and mastery of technique" Nowhere in WP:AGF or any other guideline or policy does it say that I need to assume that all wikipedia editors are experienced in the fundamentals of software development or have any other technical skills, nor is the the slightest hint that -- lacking any evidence to the contrary -- it is in any way rude to assume that someone does not know that capturing requirements should precede writing code or pointing them to a Wikipedia page that explains that concept.
You might also wish to consider whether Yuvipanda needs or wants you to "defend" him or her, especially with methods that resemble trying to put out a fire with petrol.
I asked you nicely to drop the WP:STICK. Now I am going to have to insist. If you think that I was rude -- which I was not -- take it to WP:ANI instead of hijacking this RfC with false accusations. This is my last response on this subject. Further attempts to accuse me of things that I did not do will be ignored unless you make them in the appropriate venue. --Guy Macon (talk) 04:25, 1 July 2013 (UTC)
  • Will this restriction be placed into the rights of the article/talk pages or from the editor's permission rights? There may be some interesting possibilities depending on which end the rights or permissions are inserted. For instance: editors could have a permitted list or a blocked list of groups or users and control their own pages. Certain groups would be permanently permitted to edit their comments and less as desired with experience or stature.. 174.118.153.129 (talk) 16:55, 28 June 2013 (UTC)
  • Everything I have read indicates that the basic scheme will be Role-based access control. Keep in mind that the old and new systems will have to coexist side by side for a while --Guy Macon (talk)
  • I'm sorry, but the English Wikipedia is not in a position to provide policy for all wikis. Flow is a movement-wide project. The English Wikipedia may advise (and hopefully will) and provide what it believes are its requirements, but it is not in a position of authority for 800+ other wikis.--Jorm (WMF) (talk) 17:07, 28 June 2013 (UTC)
    • This RFC concerns the English Wikipedia only, I don't see anything that would let presume otherwise, even though it may be a bit premature. If editing other users' comments is a userright, it should be configurable at project level ? Cenarium (talk) 17:43, 28 June 2013 (UTC)
      • The English Wikipedia is in a position to request an alternate mechanism to "Flow" for talk pages if it is not appropriate; perhaps going back to subpages (Article/Talk). On the other hand, it seems unlikely that this would be configurable at the project level; it's more likely that "editFlowComments" would be a separate userright, and the project can choose where to bundle it. (I know, that still makes it a project decision, for the most part, but it could even be unbundled.) — Arthur Rubin (talk) 19:12, 28 June 2013 (UTC)
        • Could you two please move the above discussion to a separate section? These are things that are well worth discussing, but not in the middle of an RfC that is asking a specific question. --Guy Macon (talk) 22:47, 28 June 2013 (UTC)
  • Comment: Will we have an edit history for each comment? If someone edits my comments, I want it pointed out in an edit history that another user has edited my comments, and the comment marked as such until I review the edits.Martin451 (talk) 00:46, 29 June 2013 (UTC)
  • Comment: This should be an all or nothing approach. Either let everyone edit comments made by others, or go down the other approach where only trusted users are allowed to edit, and only for gross violations (BLP,personal attacks etc.), if I make a mistake in a link, then post a new message with the correct link. Third option is to let the user decide who can edit their comments.Martin451 (talk) 00:46, 29 June 2013 (UTC)
  • How would each of the above be applied in the case of obvious vandalism? An article talk page comment that just says "!!!GO PIGGERS!!!" is still an article talk page comment and deleting it is a form of editing it. --Guy Macon (talk) 01:03, 29 June 2013 (UTC)

Arbitrary Section Break 1

A Gentle Reminder: This RfC is for answering one specific question: "Who will the software allow to edit another person's article talk page comments in Flow?". If you want to discuss anything else, please put it in a separate section. Some minor explanatory discussion about Flow itself is OK; for example if someone asks "will the software still allow a user to forge another user's signature?" it would be appropriate to point out that whatever we decide about editing other people's comments, signatures will be automatic and uneditable for everyone. It would not be appropriate to then go off on a tangent discussing, for example, whether you should be allowed to edit your own signature. That discussion belongs outside of this RfC. I need all of your help to keep this RfC on topic. --Guy Macon (talk) 23:29, 28 June 2013 (UTC)

This entire section appears to me to conflate two processes and ideas. They are conflated in wikitext and talk pages because of software limitations, which is saddening. They are:
  1. Vandalism control / Removal / Moderation
  2. Actual comment editing.
The problem here is that (currently) one addresses vandalism via editing comments. This is a limitation inflicted by the software. New, better software will not have this limitation and will be able to handle moderation differently, better, and faster.
We are saying that it is insane that any user can just go in and change the meaning of my words at whim. This is vandalism, and a petty vandalism, but one we can solve for simply by limiting the ability for people to do that.
Removing posts that say "PIGGERS IS AWESOME!" is a different matter. That's comment deletion or oversight, not editing.
"moderation" != "editing".--Jorm (WMF) (talk) 01:43, 1 July 2013 (UTC)
It may very well be that the policy that is in the lead in the RfC right now is "insane" (I voted against it) but that is for the community to decide. Currently any editor has the ability to remove "PIGGERS IS AWESOME!" from the middle of another editor's comment while leaving the rest of the comment in place. You may think that this should be changed and that any editor should be able to delete a comment but only admins should be allowed to deleted part of one (I personally think that IP editors shouldn't be allowed to do either) but unless you can explain how some essential feature of Flow absolutely requires such a change, it isn't your place to make that decision. --Guy Macon (talk) 04:25, 1 July 2013 (UTC)

This discussion seems kind of pointless to me. The software-design question amounts to "Will the ability to edit (or vandalize) other people's comments be available based on some userright or another?", and the answer is already yes (because we've already been told that at least admins will be able to, and how else would admins be able to do this, if not because some userright makes it possible?). Who exactly will get the userright is not something that the WMF is likely to care about, just like they don't much care who we make admins or who we make rollbackers. WhatamIdoing (talk) 20:17, 1 July 2013 (UTC)

Is it correct that there will be no history? If so, nobody should change others comments as long as they are posted as CC-BY-SA 3.0 License... 90.184.223.136 (talk) 12:38, 21 August 2013 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Deletion

Jorm comments above that it is currently planned that deleted posts and topics will remain on the board, just noting that the topic was deleted and by whom. So you won't have to check the history to see that this has happened. This is problematic. Being on the receiving end of abuse is an all too common occurrence on talk pages, and there absolutely must be a way for a non-privileged user to eradicate text to the same degree that it's currently possible to do so. — Scott • talk 20:51, 8 August 2013 (UTC)

I don't think he means that the entire message will be left on the board, but rather that the fact the thread existed will remain. So instead of seeing the original message:

I accuse you of edit warring on this article that you've never even touched! Your existence is a blight upon humanity, and you should be ashamed to breathe! User:Example 21:47, 8 August 2013 (UTC)


—This post has been deleted by WhatamIdoing (talk) at 21:47, 8 August 2013 (UTC), so pretend you didn't read it, okay?

you would likely see something more like

This post was deleted by WhatamIdoing (talk) at 21:47, 8 August 2013 (UTC). Undelete (authorized accounts only)

If the post simply disappeared, then I'm not sure how you would find it again, in the event that you ever wanted to undelete it (e.g., because you clicked on the wrong post when you were deleting things). WhatamIdoing (talk) 21:47, 8 August 2013 (UTC)
Have you ever seen harassment at Wikipedia? It's surprisingly rare, but it does happen and it's totally destructive. It's destructive not just for the person being harassed, but for any decent person who notices because no decent person likes to be part of a community that has no tools for dealing with such obvious exploitation of anyone can edit. As Scott explained, there must be a way for rubbish to be removed totally because WP:DENY is our only tool—any attempt at blocks of wide IP ranges is met with howls at ANI. The abuser would regard the fact that they can get half a dozen "This post was deleted..." messages on a talk page as a win for their side, and everyone watching would think, "oh—that's X saying Y again". Complete removal is necessary not just for harassment but for other kinds of ratbaggery, for example, from zealots pushing their cause on article talk pages where again they would regard a wall of "This post was deleted..." as flags marking their progress towards campaign victory. Johnuniq (talk) 03:07, 9 August 2013 (UTC)
In your opinion, does the example I gave above indicate who's post it was? How would anyone know whether it was his post or someone else's? How would this be any different from regarding the talk-page history as a trophy? WhatamIdoing (talk) 15:33, 9 August 2013 (UTC)
How is it different? A history page is not in the face of everyone reading the conversation. Diego Moya (talk) 16:46, 9 August 2013 (UTC)
If the post simply disappeared, then I'm not sure how you would find it again... - that's why I said to the same degree that it's currently possible to do so. In other words, page history currently provides a mechanism for locating removed text. As it stands, the current proposal loses this functionality and gains the problematic scenario that John describes. — Scott • talk 12:15, 9 August 2013 (UTC)
Each post is its own page. There is no unified page history. Imagine that I have a thousand subpages with names like User talk:WhatamIdoing/39582-03-20358920952. None of the are linked on a visible page, and someone has deleted a dozen entire pages, possibly without my knowledge or permission. How would you find the deleted pages? WhatamIdoing (talk) 15:33, 9 August 2013 (UTC)
  • What!!!???!!!!???? That is terribly non-functional. There has to be a way to see all edits to the same page, otherwise the result is not a wiki, and you've broken the number 1 functionality that people depends upon since 10 years ago. The problem you mention is only the tip of the ice-berg of everything that can be wrong without a common edit history. A single history for the whole page is the mechanism that the community uses to perform all kind of supervision. You eliminate that feature, and there's no way to review what other people is doing with the content. Diego Moya (talk) 16:01, 9 August 2013 (UTC)
  • Each comment is its own "whole page". You will be able to see the page history for each comment/page—but, just like now, you can only see that page history if you know the exact name of the page. WhatamIdoing (talk) 20:46, 10 August 2013 (UTC)
  • I understand that, and that's exactly what's problematic. But it doesn't need to be that way; if you have a logical concept of "thread" that includes more than one comment, there has to be a way to find which comments belong to it (even if a comment belongs to several threads, that's a separate concern to this concept). Diego Moya (talk) 21:25, 10 August 2013 (UTC)
Er, I'm reporting a bug in your design. Solving it isn't my job, and especially not inventing solutions to problems created by a complex new infrastructure I have absolutely no knowledge of. — Scott • talk 16:14, 9 August 2013 (UTC)
In any case, there's no sense in saying that there can't be a unified history page. There is a way to find all posts that belong to a thread, otherwise you couldn't show them and notify people subscribed to it. It should be possible to use that same mechanism to find all posts' histories and merge them on a single page. Maybe it wouldn't be terribly efficient, but accessing history is also not the most common operation. Diego Moya (talk) 16:58, 9 August 2013 (UTC)
It might be possible, but you're still thinking about "a comment" happening exclusively on "a page". That's not the idea here. The idea here is more like "a comment" is made, and it (if wanted) simultaneously appears on multiple pages. Your "unified history page" would be the equivalent of every single edit to every single AFD and every single subpage of AFD appearing at WP:AFD's history. That's probably not what you really want. WhatamIdoing (talk) 20:46, 10 August 2013 (UTC)
Multiple post is no excuse. If you have a concept of a "page" or a "thread" or a "tag", it should be possible to find all comments that belong to that one page and find their history; it's no different to what we have now, if I post the same comment to several pages with the current system (by copy-pasting it) it will show at the history of each page, and it doesn't mean that all those pages have their histories merged; there's no need for the new system to behave differently. Your analysis of the problem (that this somehow would mean merging all the histories of all possible threads) makes no logical sense to me. Diego Moya (talk) 21:23, 10 August 2013 (UTC)
WhatamIdoing, this shouldn't be a problem. So a comment can appear on multiple pages, no problem. Comment X appears on page A, B, C. Comment Y appears on page B, C. Comment Z appears on page B. Comment history for page A should only show X. Comment history for page B should show comments X, Y, Z. Comment history for page C should show comments X, Y. I really don't understand what the fuss is about, this type of sorting should be incredibly simple. We need unified comment histories for each article/page and it shouldn't be rocket science to get them. Computer science, sure, but it's freshman-level computer science. Not to mention, if there isn't something like that, then the edit summary field below a post editing box becomes incredibly worthless and one-line summaries of an edit can be fairly valuable in quick reviews. Banaticus (talk) 00:04, 23 August 2013 (UTC)

Can I roll multiple conversations into one conversation in Flow?

Can I roll multiple conversations into one conversation in Flow? For instance, in the past a user would post on my page and ask me about something and I'd respond. They'd then respond back by creating an entirely new conversation and I'd roll that into the first conversation then respond:

Some Subject
A post about that subject.

My response

Some Subject


A response to my response

Some Subject
A post about that subject.

My response
A response to my response.
I respond again

Can I do that with Flow? Banaticus (talk) 00:27, 23 August 2013 (UTC)

Exactly who has the power to combine threads has not been established, as far as I know, but combining and splitting threads are among the core workflows. In other words, I'm not sure you can do it (but, as owner of the board, it seems likely), but it can be done. (I'm writing this as someone who is critical of the proposed release of Flow, but this wouldn't be a problem.) — Arthur Rubin (talk) 01:29, 23 August 2013 (UTC)

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)

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.

  • [10] Demonstrating new templates.
  • [11] Discussing IPA technicalities, with IPA templates and examples probably copied from an edit-window.
  •  Done
  • [12] Various {{User}} type templates, often used in multiples.
  •  Done
  • [13] Numerous {{tl}} templates.
  • [14] Copying example code (and embedding it in a < nowiki > or < code >), to explain something.
  •  Done
  • [15] Table-Code excerpt from article.
  •  Done
  • [16] Template:Gi/Tq used to highlight quoted remarks that are being replied to.
  •  Done
  • [17] 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
    IPA template
  • {{checkuser}} template
    {{checkuser}} template
  • nowiki example markup
    nowiki example markup
  • gi/tq template
    gi/tq template
  • magic word
    magic word
Perhaps I could add one more example, from my own talk page:
  • [18] 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!
    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)

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 ([19]). 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 ([20]). 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 [21]). The problem is that, for example, Template:S-start ([22]) 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)
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 ([23]). 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 [24], [25], [26])... 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)

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:
  1. Ankit blocks Barbara. The block notice workflow Topic is started on Barbara's board.
  2. 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"
  3. 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)
  • 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)

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)

Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia_talk:Flow/Archive_3&oldid=1228836024"