Will this affect all pages in talk namespaces if it is rolled out Wiki-wide on one of the wikis, or can this be selectively (de-)activated? I know that on English Wikipedia, some people use the talknamespaces to store scratchpad information in subpages, while developing drafts on the subjectspace subpages. -- 65.94.76.126 12:08, 24 May 2013 (UTC)
Topic on Talk:Flow Portal/Archive2
This is an interesting question. I really can't answer with any authority until we get deeper into development.
I can't imagine that we'd think it a good idea to eliminate scratchpad places. We may actually create special scratchpad places to avoid namespace confusion.
Would every page acquire a scratch: namespace, as they currently have a talkpagespace and subjectpagespace? scratchpagespace. (this would then create a namespace location to store Template workpages that on English Wikipedia currently reside as subpages) ?
I rather like the idea of a Scratch: namespace. I think maybe we'll talk about it.
The problem, though, lies in that we might end up creating a "shadow" discussion zone. Some people who hate Flow (for whatever reason) may decide to only communicate on the Scratchpads. That would be an unfortunate turn of events.
Should I start laughing? Are you actually aware of what you just said?
If people see the need to avoid Flow, this will be because of limitations of this new discussion system. If flow is thought through properly it will fulfill the needs of all editors, therefore making such workarounds unnecessary.
When you already start mistrusting editors at this point (and it's the editors you're writing Flow for, right?) you probably should stop development of Flow immediately.
Patrick: are you telling me that every piece of software we work on should serve every possible use case of every possible editor?
Jorm is not saying "a majority of users will ignore Flow". He is not saying "A plurality of users will ignore Flow". He is saying "even if fifty people resort to scratchpads, we have a problem because discussion has now fragmented". I'm finding the lack of good faith you're continuing to show here frankly disappointing.
No, but for most editors. And as the comments on FLOW show, most editors are concerned with the way FLOW might constrain editing.
I see your point that it might not be a "majority" of users resorting to scratchpads. But if Jorm is considering not implementing scratchpads at all because of those who do, he is afraid it could be a notable amount of editors (not just "fifty people" he would probably not be worried about).
Now explain to me: If Jorm is afraid a notable amount of editors could resort to scratchpad discussion — why is this amount of editors not notable enough to redesign FLOW to fit their needs?
I rather think that something along the lines of English Wikipedia's "talk in article" warning template can be used to warn users of improper use of scratch space. People do that in articles now, and are handled by informing them of the talk page and how to use it.
I can't see that happening. People will leave rather than be told how to work together. Personally I think all the problems listed on the main page could be solved much easily; we already have notifications, make a notification if there is a reply in a section you've commented in. Simple. It can't be that hard to make talk pages autosigning, although what about Project pages, where posts may or may not need to be signed? At least now if you want to add a signature you learn how to do so once and then it's sorted. New users are just going to get more confused. Reply button. The en.wiki teahouse already has one which seems to work fine. Sorted. I could honestly see a consensus, at least on enwiki, to oppose this change and if it is forced upon us, people will leave.
People always threaten to leave. They almost never do. In fact, if you wait a couple of months and go back to the loudest complainers, they often can't even tell you what the differences are.
As for the difficulty of autosigning, you've exactly identified the problem: it is hard to make talk pages autosigning because there's currently no way for the software to know whether your change is one of those that needs to be signed or not. Flow will provide that distinction, and autosign all the ones that ought to be signed.
Well, It basically achieves this by prohibiting changes that wouldn't need to be signed at all, so you can hardly call this a feature.
Oh, and when you start comparing Wikipedia to Facebook (see link) I'll leave immediately... No, actually I won't, but Facebook and Flow are (should be) completely different:
- Facebook wants people to be involved in endless, and pointless discussions as long as possible. Quantity but quality!
- Wikipedia needs an efficient discussion system, so basically the opposite.
Why do you believe that we won't be able to add things that are unsigned? Please go read Flow Portal/Use cases, and pay attention to all that talk about the importance of unsigned stuff like WikiProject banners. Search for the keyword "metadata" on that page: a method of accommodating this need has been planned from the beginning.
I neither said nor implied that we wouldn't be able to add things that are unsigned.
But a default comment will be signed with Flow, and there is nothing to change this behavior. Everything else must go into the unstructured section you are talking about.
So there is no "magic" auto-sign algorithm involved in Flow, just restrictions installed to remove any need of such an algorithm.
Perhaps you would like to explain what "prohibiting changes that wouldn't need to be signed" means, if it doesn't mean "we wouldn't be able to add things that are unsigned."
I don't understand the difference (since one implies the other), but what I was saying is, that we can't edit the posts of others (e.g. to re-indent, fix some link, etc.) so every edit we can make is posting a comment which automatically gets signed.
Everything else we might post goes into the unstructured edit section where signing isn't necessary.
You seem to be assuming a lot here. You're assuming that Flow will have an unintuitive, segmented, and restrictive interface. Seeing as Flow doesn't exist yet, it's difficult to say what it will look like and how it will function, but I doubt it will be as you think.
If you wish to make suggestions to the development team, it makes their job a lot easier if you do not work from your assumptions about what the software might end up looking like, but instead explain to them exactly what you want the software to be able and unable to do, in broad general terms.
The difference is that you will be able to add unsigned material on a talk page—in the unstructured section. You have already been promised the ability to add unsigned material.
There will be much less need to edit other people's comments (e.g., re-indenting), but it is currently planned for at least admins and perhaps other trusted users to be fix problems with comments (although this will be noted, just like it's noted now in the talk page's history). I'm sure that people whose comments have been vandalized (e.g., removing the word not) or wrongly blanked will appreciate this limitation.
I hope that the ability to edit others' comments will be a separate userright that can be given to different usergroups on a per-wiki basis.
Per the discussion at English Wikipedia, it seems that a scratchspacepage for every talkspacepage/subjectspacepage will be required, since FLOW will not render wikicode the same as the subjectspacepage will, so showing examples of sample revisions to the subjectspacepage will need to be placed onto the scratchspacepage as a FLOW based talkspacepage will just not support such things.
That's part of what I was trying to say about Flow. Flow will, at least in Jorm's concept, not be suitable for discussion of article Wikimarkup, and hence not be suitable for article talk pages.
That's not what I've said at all. Please do not spread mis-information while attributing it to me.
I didn't quote you. I said that your concept of Flow (not allowing editing of Wikimarkup and rendering of all Wikimarkup suitable for articles, including templates) would not be suitable for discussion of Wikimarkup.
Do disagree with the statement that your concept of Flow does not allow editing and rendering of all Wikimarkup, including templates?
I'm sorry, but I'm not going to get into discussions wherein the spirit of my words is corrupted to serve a point which I am not making.
It's true that you're not making the point that Flow will not be suitable for article talk pages; nor I think that Arthur wanted to attribute that point to you. We are making that point, based on the words you've used to explain what Flow will and won't be able to do.
I've tried to summarize this issue, over at the end of the w:Wikipedia talk:Flow/Archive 3#Supported Wikitext thread, with a handful of clear examples.
For what it's worth, when the current Flow code "occupies" a talk namespace, /subpages are unaffected. Subject to change, early days, etc.