I've gone ahead and written up two Functional Specification documents:
http://www.mediawiki.org/wiki/Flow_Portal/Functional_Specifications/Moderati...
* This reflects the conversations we had on Thursday and Friday and fleshes out some behaviors.
http://www.mediawiki.org/wiki/Flow_Portal/Functional_Specifications/Search_a...
* This describes (mostly) how the local Board search will work. It gets kind of technical with the language (e.g., "compositional intersection tokens") but I think it's readable for the audience. I did this one because I was getting asked about it.
I'm going to be creating several of these and breaking them up into sections. Stuff like "this is how timestamps behave" and "this is how edit windows behave" and the like. Where necessary I'll start making mockups (some of this will be easier to do in photoshop than making interactive ones, especially given the speed at which Andrew and Erik are producing code).
Off the top of my head, here is my current list of TODOs:
* User renames / Account merges (merge boards) * Board * Single Topic * Feed * Editors * Scratchpads * Timestamp behavior * History behavior
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
On Sun, Aug 18, 2013 at 5:28 PM, Brandon Harris bharris@wikimedia.orgwrote:
Scratchpads
What is a scratchpad, ten words or less? :-)
Steven
Would it be possible as these behaviors are implemented for us to create automated UI-level acceptance tests for them, and run the tests against code in beta labs? If we could create these as we go along, they would serve as a growing set of regression tests. Also, it would be nice to run the tests in all supported browsers, including Internet Explorer if we can. Knowing that stuff works in IE as we go along should save rework later on.
The descriptions of the stories in Mingle are a bit sparse. https://mingle.corp.wikimedia.org/projects/flow/cards/grid?color_by=priority...
On Sun, Aug 18, 2013 at 5:28 PM, Brandon Harris bharris@wikimedia.orgwrote:
I've gone ahead and written up two Functional Specification
documents:
http://www.mediawiki.org/wiki/Flow_Portal/Functional_Specifications/Moderati...
* This reflects the conversations we had on
Thursday and Friday and fleshes out some behaviors.
http://www.mediawiki.org/wiki/Flow_Portal/Functional_Specifications/Search_a...
* This describes (mostly) how the local Board
search will work. It gets kind of technical with the language (e.g., "compositional intersection tokens") but I think it's readable for the audience. I did this one because I was getting asked about it.
I'm going to be creating several of these and breaking them up
into sections. Stuff like "this is how timestamps behave" and "this is how edit windows behave" and the like. Where necessary I'll start making mockups (some of this will be easier to do in photoshop than making interactive ones, especially given the speed at which Andrew and Erik are producing code).
Off the top of my head, here is my current list of TODOs: * User renames / Account merges (merge boards) * Board * Single Topic * Feed * Editors * Scratchpads * Timestamp behavior * History behavior
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
This is tremendously helpful, thanks! I'll start up an MVP sub-page, too :)
I've been mulling over the interwiki stuff, and I realized that one of the big benefits of not working on the Feed view in the first release is that we don't necessarily have to worry about all the thorny "what happens when this board is semi-protected on project x and I'm an admin on project y but haven't been autoconfirmed on project x?" issues yet – focusing on individual boards means we're sticking closer to the current talk page mental model, which is very much per-project based. Deploying to a WikiProject discussion space (or the Flow portal talk pages...) will give us an opportunity to see if and how we want to aggregate topics from multiple boards and display them to the user, but it's not a hard first release requirement.
Also, I seem to have inherited a bounty of ee-related mailing lists – do people care which one we use to share work like this? I figured the e2 list (E2 development team) might be better, as this list (Editor Engagement) has a broad WMF and non-WMF audience and seems more appropriate for general idea-sharing, rather than announcements aimed at specific teams of staffers. I don't care as long as we're consistent; I'm just worried that if Flow announcements start to dominate here, volunteers and non-EE staffers will feel less comfortable posting non-Flow related things.
On Sun, Aug 18, 2013 at 5:28 PM, Brandon Harris bharris@wikimedia.orgwrote:
I've gone ahead and written up two Functional Specification
documents:
http://www.mediawiki.org/wiki/Flow_Portal/Functional_Specifications/Moderati...
* This reflects the conversations we had on
Thursday and Friday and fleshes out some behaviors.
http://www.mediawiki.org/wiki/Flow_Portal/Functional_Specifications/Search_a...
* This describes (mostly) how the local Board
search will work. It gets kind of technical with the language (e.g., "compositional intersection tokens") but I think it's readable for the audience. I did this one because I was getting asked about it.
I'm going to be creating several of these and breaking them up
into sections. Stuff like "this is how timestamps behave" and "this is how edit windows behave" and the like. Where necessary I'll start making mockups (some of this will be easier to do in photoshop than making interactive ones, especially given the speed at which Andrew and Erik are producing code).
Off the top of my head, here is my current list of TODOs: * User renames / Account merges (merge boards) * Board * Single Topic * Feed * Editors * Scratchpads * Timestamp behavior * History behavior
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
On 08/19/2013 02:10 PM, Maryana Pinchuk wrote:
Also, I seem to have inherited a bounty of ee-related mailing lists – do people care which one we use to share work like this? I figured the e2 list (E2 development team) might be better, as this list (Editor Engagement) has a broad WMF and non-WMF audience and seems more appropriate for general idea-sharing, rather than announcements aimed at specific teams of staffers. I don't care as long as we're consistent; I'm just worried that if Flow announcements start to dominate here, volunteers and non-EE staffers will feel less comfortable posting non-Flow related things.
I'd prefer technical discussions were on a public mailing list, which E2 is not. I think some volunteers are interested in these details. If people feel it's flooding EE (not sure that's the case yet), there are other options:
1. Wikitech. Although that's already busy, people are used to it, and I think willing to filter/mark as read topics that don't interest them. 2. Making a new list (e.g. wikidata-tech does this).
BTW, these Flow specs look very helpful and detailed. I hope to be able to read some of them fully later.
Matt Flaschen