For a while now, the Collaboration team has been working on Flow, the structured discussion system. I want to let you know about some changes in that long-term plan.
While initial announcements about Flow said that it would be a universal replacement for talk pages, the features that were ultimately built into Flow were specifically forum-style group discussion tools. But article and project talk pages are used for a number of important and complex processes that those tools aren't able to handle, making Flow unsuitable for deployment on those kinds of pages.
To better address the needs of our core contributors, we're now focusing our strategy on the curation, collaboration, and admin processes that take place on a variety of pages. Many of these processes use complex workarounds -- templates, categories, transclusions, and lots of instructions -- that turn blank wikitext talk pages into structured workflows. There are gadgets and user scripts on the larger wikis to help with some of these workflows, but these tools aren't standardized or universally available.
As these workflows grow in complexity, they become more difficult for the next generation of editors to learn and use. This has increased the workload on the people who maintain those systems today. Complex workflows are also difficult to adapt to other languages, because a wiki with thousands of articles may not need the kind of complexity that comes with managing a wiki with millions of articles. We've talked about this kind of structured workflow support at Wikimania, in user research sessions, and on wikis. It's an important area that needs a lot of discussion, exploration, and work.
Starting in October, Flow will not be in active development, as we shift the team's focus to these other priorities. We'll be helping core contributors reduce the stress of an ever-growing workload, and helping the next generation of contributors participate in those processes. Further development on these projects will be driven by the needs expressed by wiki communities.
Flow will be maintained and supported, and communities that are excited about Flow discussions will be able to use it. There are places where the discussion features are working well, with communities that are enthusiastic about them: on user talk pages, help pages, and forum/village pump-style discussion spaces. By the end of September, we'll have an opt-in Beta feature available to communities that want it, allowing users to enable Flow on their own user talk pages.
I'm sure people will want to know more about these projects, and we're looking forward to those conversations. We'll be reaching out for lots of input and feedback over the coming months.
Danny Horn Collaboration team, PM
Thanks for the update. Discussion is taking place on Wikimedia-l.
Pine On Sep 1, 2015 2:27 PM, "Danny Horn" dhorn@wikimedia.org wrote:
For a while now, the Collaboration team has been working on Flow, the structured discussion system. I want to let you know about some changes in that long-term plan.
While initial announcements about Flow said that it would be a universal replacement for talk pages, the features that were ultimately built into Flow were specifically forum-style group discussion tools. But article and project talk pages are used for a number of important and complex processes that those tools aren't able to handle, making Flow unsuitable for deployment on those kinds of pages.
To better address the needs of our core contributors, we're now focusing our strategy on the curation, collaboration, and admin processes that take place on a variety of pages. Many of these processes use complex workarounds -- templates, categories, transclusions, and lots of instructions -- that turn blank wikitext talk pages into structured workflows. There are gadgets and user scripts on the larger wikis to help with some of these workflows, but these tools aren't standardized or universally available.
As these workflows grow in complexity, they become more difficult for the next generation of editors to learn and use. This has increased the workload on the people who maintain those systems today. Complex workflows are also difficult to adapt to other languages, because a wiki with thousands of articles may not need the kind of complexity that comes with managing a wiki with millions of articles. We've talked about this kind of structured workflow support at Wikimania, in user research sessions, and on wikis. It's an important area that needs a lot of discussion, exploration, and work.
Starting in October, Flow will not be in active development, as we shift the team's focus to these other priorities. We'll be helping core contributors reduce the stress of an ever-growing workload, and helping the next generation of contributors participate in those processes. Further development on these projects will be driven by the needs expressed by wiki communities.
Flow will be maintained and supported, and communities that are excited about Flow discussions will be able to use it. There are places where the discussion features are working well, with communities that are enthusiastic about them: on user talk pages, help pages, and forum/village pump-style discussion spaces. By the end of September, we'll have an opt-in Beta feature available to communities that want it, allowing users to enable Flow on their own user talk pages.
I'm sure people will want to know more about these projects, and we're looking forward to those conversations. We'll be reaching out for lots of input and feedback over the coming months.
Danny Horn Collaboration team, PM _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Thanks. So now we'll have two unmaintained extensions, LQT and Flow. Can we reverse the Flow conversion on mediawiki.org now, so that the wiki stays on the luckiest side i.e. the extension which has most users and is most likely to survive in the future? (LQT is maintained by its non-Wikimedia users, otherwise it would have broken down years ago on all Wikimedia wikis as well.)
Nemo
On 1 September 2015 at 23:21, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Thanks. So now we'll have two unmaintained extensions, LQT and Flow.
To quote Danny's email directly, "Flow will be maintained and supported". Your supposition that the extension will be unmaintained is not correct.
Thanks, Dan
Ok, that is maybe correct, but what does "maintained" and "supported" mean here? There are a lot of Feature requests for Flow to make Flow at least as productive as some LQT boards, e.g. on mediawiki.org (think about the different places for support, e.g. Support desk and extension talk pages, where we still can't move topics between boards[1], while LQT supported this). Will these feature requests be implemented or does maintained/supported only mean, that Flow will not break in production, but there will be no "new" features?
In my opinion, Flow is far away from being more productive as LQT (from a user perspective), and I think I'm not the only one, who welcomed the move to Flow with the hope, that Flow get's, in the future, the features we need/request/want, so it would feel bad to get the next unfinished (but still supported) discussion extension :(
[1] https://phabricator.wikimedia.org/T88140
Best, Florian
-----Original-Nachricht----- Betreff: Re: [Wikitech-l] Collaboration team reprioritization Datum: Wed, 02 Sep 2015 08:27:42 +0200 Von: Dan Garry dgarry@wikimedia.org An: Wikimedia developers wikitech-l@lists.wikimedia.org
On 1 September 2015 at 23:21, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Thanks. So now we'll have two unmaintained extensions, LQT and Flow.
To quote Danny's email directly, "Flow will be maintained and supported". Your supposition that the extension will be unmaintained is not correct.
Thanks, Dan
On 2 September 2015 at 07:27, Dan Garry dgarry@wikimedia.org wrote:
On 1 September 2015 at 23:21, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Thanks. So now we'll have two unmaintained extensions, LQT and Flow.
To quote Danny's email directly, "Flow will be maintained and supported". Your supposition that the extension will be unmaintained is not correct.
As a third-party MediaWiki tarball user, I'm slightly annoyed because RationalWIki took on LQT originally because WMF made it sound like it was definitely the future yep no worries. As the current sysadmin I desperately would love to set LQT on fire and put it in a bin and was hoping Flow would be the supported option. Bah, how annoying ...
Did the stuff to port LQT threads/pages to Flow ever make it to production quality?
OTOH, the problems outlined in this message are pretty much exactly what experienced Wikipedia users said when Flow was started - you need to be able to cut'n'paste slabs of wikitext (or parsoid HTML5 or whatever VE actually copies to the clipboard) from the article to the talk page, which means something VEish on talk too.
Talk pages are indeed an utter nightmare for usability. If I had a plausible answer I'd be posting it.
- d.
I want to thank the Collaboration team for taking this brave step - and yes, it's a brave step. The natural trajectory of large projects that don't quite seem to meet their promise is to keep going and going until everyone is burnt out, and it is courageous to say "this isn't going where we wanted it to" and break that cycle. Most of the people who are currently involved in Flow and the Collaboration team were not there when it started, and they joined a project that had very mixed levels of support that had very challenging and broad objectives. We as a community can learn a lot from their experience, and we really should make an effort to examine this project and use this experience to re-examine and improve the process of developing new software.
I am certain once the team has a chance to refocus, they may choose to examine workflows that are common across multiple Wikimedia projects that would benefit from improvement. Off the top of my head, creating a "deletion" wizard in collaboration with a couple of large Wikipedias might be a starting point. I suspect that the Collaboration team and the Community Tech team will find many overlaps in their work as they go forward.
Risker/Anne
On 2 September 2015 at 14:51, Risker risker.wp@gmail.com wrote:
I want to thank the Collaboration team for taking this brave step - and yes, it's a brave step. The natural trajectory of large projects that don't quite seem to meet their promise is to keep going and going until everyone is burnt out, and it is courageous to say "this isn't going where we wanted it to" and break that cycle. Most of the people who are currently involved in Flow and the Collaboration team were not there when it started, and they joined a project that had very mixed levels of support that had very challenging and broad objectives. We as a community can learn a lot from their experience, and we really should make an effort to examine this project and use this experience to re-examine and improve the process of developing new software.
+1 - it's far better to kill it now than later.
- d.
On 09/02/2015 12:35 PM, David Gerard wrote:
On 2 September 2015 at 14:51, Risker risker.wp@gmail.com wrote:
I want to thank the Collaboration team for taking this brave step - and yes, it's a brave step. The natural trajectory of large projects that don't quite seem to meet their promise is to keep going and going until everyone is burnt out, and it is courageous to say "this isn't going where we wanted it to" and break that cycle. Most of the people who are currently involved in Flow and the Collaboration team were not there when it started, and they joined a project that had very mixed levels of support that had very challenging and broad objectives. We as a community can learn a lot from their experience, and we really should make an effort to examine this project and use this experience to re-examine and improve the process of developing new software.
+1 - it's far better to kill it now than later.
Flow is not being killed.
In addition to maintaining and supporting it, we'll soon be working on rolling out a Beta feature to allow people to enable Flow on their user talk pages.
After that, we'll start work on workflows, as noted in the original email. Workflows were *always* planned to be the next stage of Flow. That's the whole reason it's called Flow.
Matt
Le 02/09/2015 21:10, Matthew Flaschen a écrit : <snip>
Flow is not being killed.
In addition to maintaining and supporting it, we'll soon be working on rolling out a Beta feature to allow people to enable Flow on their user talk pages.
Thank you Matthew! From Danny original mail I thought the whole Flow was put on hold / postponed etc.
I will be VERY happy whenever my talk pages is finally a proper discussion system and I have been waiting for that for more than a decade!
Kudos to you guys!
On Wed, Sep 2, 2015 at 6:51 AM, Risker risker.wp@gmail.com wrote:
I am certain once the team has a chance to refocus, they may choose to examine workflows that are common across multiple Wikimedia projects that would benefit from improvement. Off the top of my head, creating a "deletion" wizard in collaboration with a couple of large Wikipedias might be a starting point.
Obviously this work is still in very early stages, but deletion-related processes are definitely on our radar. AfD on enwiki was one of our case studies during early work on this, as you can tell from this slide in Danny's Wikimania presentation: https://wikimania2015.wikimedia.org/w/index.php?title=File:User%28s%29_Talk%...
I suspect that the Collaboration team and the Community Tech team will find many overlaps in their work as they go forward.
Yes, we are aware that that is likely to happen, and we'll be talking to them about that.
On Wed, Sep 2, 2015 at 6:21 AM, David Gerard dgerard@gmail.com wrote:
Did the stuff to port LQT threads/pages to Flow ever make it to production quality?
It was used to convert all LQT pages on mediawiki.org, including [[mw:Support desk]] which is probably the largest LQT page that has ever existed. So it meets the "WMF uses it" definition of production quality, at least.
I don't think we currently have good documentation on how you can convert your own wiki, but AFAIK "simply" running the convertAllLqtPages.php maintenance script on a wiki that has both LQT and Flow installed should work.
I don't know if this is correct place to bring this idea, but [[Extension:PageTriage]] is good example of a starting point. Is there any plans to work on it by collaboration team?
Best
On Wed, Sep 2, 2015 at 10:50 PM Roan Kattouw roan.kattouw@gmail.com wrote:
On Wed, Sep 2, 2015 at 6:21 AM, David Gerard dgerard@gmail.com wrote:
Did the stuff to port LQT threads/pages to Flow ever make it to production quality?
It was used to convert all LQT pages on mediawiki.org, including [[mw:Support desk]] which is probably the largest LQT page that has ever existed. So it meets the "WMF uses it" definition of production quality, at least.
I don't think we currently have good documentation on how you can convert your own wiki, but AFAIK "simply" running the convertAllLqtPages.php maintenance script on a wiki that has both LQT and Flow installed should work. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Sep 2, 2015 at 11:20 AM, Roan Kattouw roan.kattouw@gmail.com wrote:
I don't think we currently have good documentation on how you can convert your own wiki, but AFAIK "simply" running the convertAllLqtPages.php maintenance script on a wiki that has both LQT and Flow installed should work.
It turns out we do have some documentation: https://www.mediawiki.org/wiki/Flow/Converting_LiquidThreads . It's a bit more focused on how users will experience the conversion, but it does also tell you which scripts to run.
On 09/02/2015 09:21 AM, David Gerard wrote:
On 2 September 2015 at 07:27, Dan Garry dgarry@wikimedia.org wrote:
On 1 September 2015 at 23:21, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Thanks. So now we'll have two unmaintained extensions, LQT and Flow.
To quote Danny's email directly, "Flow will be maintained and supported". Your supposition that the extension will be unmaintained is not correct.
As a third-party MediaWiki tarball user, I'm slightly annoyed because RationalWIki took on LQT originally because WMF made it sound like it was definitely the future yep no worries. As the current sysadmin I desperately would love to set LQT on fire and put it in a bin and was hoping Flow would be the supported option. Bah, how annoying ...
Flow *is* the supported option, as stated in Danny's original email.
Did the stuff to port LQT threads/pages to Flow ever make it to production quality?
Yes. We've done a lot of work to ensure that neither LQT users nor LQT talk pages have been left behind.
OTOH, the problems outlined in this message are pretty much exactly what experienced Wikipedia users said when Flow was started - you need to be able to cut'n'paste slabs of wikitext (or parsoid HTML5 or whatever VE actually copies to the clipboard) from the article to the talk page, which means something VEish on talk too.
Flow has VE support. However, simply having a free-form area is not the full solution. We need to actually make these workflows easier for users (not require them to copy and paste templates around), which is the next step.
Matt
On 09/02/2015 02:21 AM, Federico Leva (Nemo) wrote:
Thanks. So now we'll have two unmaintained extensions, LQT and Flow.
As noted, Flow is not unmaintained.
Can we reverse the Flow conversion on mediawiki.org now, so that the wiki stays on the luckiest side i.e. the extension which has most users and is most likely to survive in the future?
Extensions are not maintained by 'luck'. They are maintained by hard work. We've done much of that work, to make sure LQT pages are not abandoned.
(LQT is maintained by its non-Wikimedia users, otherwise it would have broken down years ago on all Wikimedia wikis as well.)
The implication that only non-Wikimedia developers have maintained LQT is false, as a brief review of the commit log will show.
Matt Flaschen
that only non-Wikimedia developers have maintained LQT is false, as a brief review of the commit log will show.
I said "non-Wikimedia users". Not sure what log you've been looking to, but I did `git log --no-merges -- . ':(exclude)i18n'` and I confirm what I said. The only exception I found so far is T104421 where you fixed a fatal (thanks!). Other than that the only bug fixes I see are some in Flow migration.
Nemo
On 09/03/2015 03:54 AM, Federico Leva (Nemo) wrote:
that only non-Wikimedia developers have maintained LQT is false, as a brief review of the commit log will show.
I said "non-Wikimedia users". Not sure what log you've been looking to, but I did `git log --no-merges -- . ':(exclude)i18n'` and I confirm what I said. The only exception I found so far is T104421 where you fixed a fatal (thanks!). Other than that the only bug fixes I see are some in Flow migration.
Bug fixes are only one form of maintenance. Performance improvements are also important (speed is a feature), as are changes coordinated with other repositories (this prevents bit rot).
I got to over ten of these before I stopped counting.
That doesn't even count maintenance changes that are partly for LQT->Flow, but also useful in their own right.
And the bug fix you gave is not the only recent one.
Matt Flaschen
1. Regarding Flow and LQT on mediawiki.org:
On Tue, Sep 1, 2015 at 11:21 PM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Can we reverse the Flow conversion on mediawiki.org now,
Technically, I think that would be challenging. All LiquidThreads carefully redirect to Flow topics, e.g. https://www.mediawiki.org/wiki/Thread:Project:Current_issues/Adding_a_dev_na... . Extension:LiquidThreads is still enabled on mw.org, but $wgLiquidThreadsFrozen is true.
so that the wiki stays on the luckiest side i.e. the extension which has most users and is most likely to survive in the future? (LQT is maintained by its non-Wikimedia users, otherwise it would have broken down years ago on all Wikimedia wikis as well.)
We can have a conversation about the future of talk pages on mediawiki.org , where you can propose unfreezing LQT. I guess https://www.mediawiki.org/wiki/Project:Current_issues is the place for it, or a Phab task. I'm going to talk to Danny Horn first. FWIW I far prefer Flow for feature discussions.
2. IMO, Flow fully achieved two points on https://www.mediawiki.org/wiki/Flow?oldid=1870919 [1]; and it's more efficient for me. The recent DWIM ("Do what I mean") improvements while you're writing a post are a delight. Thanks Collaboration team <3 !
To better address the needs of our core contributors, we're now focusing our strategy on the curation, collaboration, and admin processes that take place on a variety of pages. Many of these processes use complex workarounds -- templates, categories, transclusions, and lots of instructions -- that turn blank wikitext talk pages into structured workflows. There are gadgets and user scripts on the larger wikis to help with some of these workflows, but these tools aren't standardized or universally available.
As these workflows grow in complexity, they become more difficult for the next generation of editors to learn and use. This has increased the workload on the people who maintain those systems today. Complex workflows are also difficult to adapt to other languages, because a wiki with thousands of articles may not need the kind of complexity that comes with managing a wiki with millions of articles. We've talked about this kind of structured workflow support at Wikimania, in user research sessions, and on wikis. It's an important area that needs a lot of discussion, exploration, and work.
Starting in October, Flow will not be in active development, as we shift the team's focus to these other priorities. We'll be helping core contributors reduce the stress of an ever-growing workload, and helping the next generation of contributors participate in those processes. Further development on these projects will be driven by the needs expressed by wiki communities.
This sounds a lot like PageTriage, which at best was a mixed success. I hope the team is able to extract lessons from that extension and apply them to whatever they intend to work on.
-- bawolff
On 3 September 2015 at 07:44, Brian Wolff bawolff@gmail.com wrote:
To better address the needs of our core contributors, we're now focusing our strategy on the curation, collaboration, and admin processes that take place on a variety of pages. Many of these processes use complex workarounds -- templates, categories, transclusions, and lots of instructions -- that turn blank wikitext talk pages into structured workflows. There are gadgets and user scripts on the larger wikis to help with some of these workflows, but these tools aren't standardized or universally available.
As these workflows grow in complexity, they become more difficult for the next generation of editors to learn and use. This has increased the workload on the people who maintain those systems today. Complex workflows are also difficult to adapt to other languages, because a wiki with thousands of articles may not need the kind of complexity that comes with managing a wiki with millions of articles. We've talked about this kind of structured workflow support at Wikimania, in user research sessions, and on wikis. It's an important area that needs a lot of discussion, exploration, and work.
Starting in October, Flow will not be in active development, as we shift the team's focus to these other priorities. We'll be helping core contributors reduce the stress of an ever-growing workload, and helping the next generation of contributors participate in those processes. Further development on these projects will be driven by the needs expressed by wiki communities.
This sounds a lot like PageTriage, which at best was a mixed success. I hope the team is able to extract lessons from that extension and apply them to whatever they intend to work on.
"at best was a mixed success" speaking as someone who has used it extensively, that is not the case. If you mean there are lessons to be learned around ensuring we have generalisable solutions to specific workflows, rather than project-specific solutions to project-specific workflows, I share your hope.
-- bawolff
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
This sounds a lot like PageTriage, which at best was a mixed success. I hope the team is able to extract lessons from that extension and apply them to whatever they intend to work on.
"at best was a mixed success" speaking as someone who has used it extensively, that is not the case. If you mean there are lessons to be learned around ensuring we have generalisable solutions to specific workflows, rather than project-specific solutions to project-specific workflows, I share your hope.
The fact that its almost impossible to use outside enwiki, would be one of the main factors of why I would call its success mixed (One of the goals even was "allow expansion and modification of the system to support different backend systems and logic screens."). I do hope we do not repeat that limitation with new systems.
The other reason I would call it mixed, is that the majority of patrolling even on enwiki, still takes place through the other interface (I believe. I'm not very familiar with patrolling on enwiki, so I may be misunderstanding something here)
Stats for this August: MariaDB [enwiki_p]> select log_type, log_action, count(*) from logging where log_type in ( 'pagetriage-curation', 'pagetriage-deletion', 'patrol' ) and log_timestamp > '20150800000000' and log_timestamp < '20150899000000' group by log_type, log_action order by count(*); +---------------------+------------+----------+ | log_type | log_action | count(*) | +---------------------+------------+----------+ | patrol | NULL | 4 | | pagetriage-curation | unreviewed | 134 | | pagetriage-deletion | delete | 1132 | | pagetriage-curation | delete | 1132 | | pagetriage-curation | tag | 2170 | | pagetriage-curation | reviewed | 10913 | | patrol | patrol | 184269 | +---------------------+------------+----------+ 7 rows in set (3.75 sec)
I'm not sure what level of popularity was targeted, but 6% market share (4.6% if you count by unique users instead of total number of patrol actions) doesn't seem like a run away success.
Its certainly not a failure. But I'm not sure I would call it a full success either due to its lack of flexibility and luke-warm adoption numbers.
-- bawolff
On 9/3/15, Brian Wolff bawolff@gmail.com wrote:
This sounds a lot like PageTriage, which at best was a mixed success. I hope the team is able to extract lessons from that extension and apply them to whatever they intend to work on.
"at best was a mixed success" speaking as someone who has used it extensively, that is not the case. If you mean there are lessons to be learned around ensuring we have generalisable solutions to specific workflows, rather than project-specific solutions to project-specific workflows, I share your hope.
The fact that its almost impossible to use outside enwiki, would be one of the main factors of why I would call its success mixed (One of the goals even was "allow expansion and modification of the system to support different backend systems and logic screens."). I do hope we do not repeat that limitation with new systems.
The other reason I would call it mixed, is that the majority of patrolling even on enwiki, still takes place through the other interface (I believe. I'm not very familiar with patrolling on enwiki, so I may be misunderstanding something here)
Stats for this August: MariaDB [enwiki_p]> select log_type, log_action, count(*) from logging where log_type in ( 'pagetriage-curation', 'pagetriage-deletion', 'patrol' ) and log_timestamp > '20150800000000' and log_timestamp < '20150899000000' group by log_type, log_action order by count(*); +---------------------+------------+----------+ | log_type | log_action | count(*) | +---------------------+------------+----------+ | patrol | NULL | 4 | | pagetriage-curation | unreviewed | 134 | | pagetriage-deletion | delete | 1132 | | pagetriage-curation | delete | 1132 | | pagetriage-curation | tag | 2170 | | pagetriage-curation | reviewed | 10913 | | patrol | patrol | 184269 | +---------------------+------------+----------+ 7 rows in set (3.75 sec)
I'm not sure what level of popularity was targeted, but 6% market share (4.6% if you count by unique users instead of total number of patrol actions) doesn't seem like a run away success.
Its certainly not a failure. But I'm not sure I would call it a full success either due to its lack of flexibility and luke-warm adoption numbers.
-- bawolff
I just realized I was counting autopatrol entries in with the other patrol log entries, which is rather unfair to PageTriage. If you discount autopatrol, then you get about 34% of patrol actions being done via page triage (18% if you count by number of unique users instead of total patrol actions). Well perhaps still not taking over the patrolling world, that's a much more respectable percentage of the market share.
I still hope lessons, both positive and negative, can be extracted from PageTriage, when embarking on similar projects, and in particular, I hope that future solutions can be used by all wikis where applicable, not just enwiki.
-- bawolff
p.s. For reference, in case anyone wants to dispute my numbers.
MariaDB [enwiki_p]> select log_type, log_action, count(distinct log_user) from logging where log_type in ( 'pagetriage-curation', 'pagetriage-deletion', 'patrol' ) and log_timestamp > '20150800000000' and log_timestamp < '20150899000000' and log_params not like '%auto";i:1;%' group by log_type, log_action; +---------------------+------------+--------------------------+ | log_type | log_action | count(distinct log_user) | +---------------------+------------+--------------------------+ | pagetriage-curation | delete | 98 | | pagetriage-curation | reviewed | 230 | | pagetriage-curation | tag | 123 | | pagetriage-curation | unreviewed | 53 | | pagetriage-deletion | delete | 98 | | patrol | patrol | 1252 | +---------------------+------------+--------------------------+ 6 rows in set (1.05 sec)
MariaDB [enwiki_p]> select log_type, log_action, count(*) from logging where log_type in ( 'pagetriage-curation', 'pagetriage-deletion', 'patrol' ) and log_timestamp > '20150800000000' and log_timestamp < '20150899000000' and log_params not like '%auto";i:1;%' group by log_type, log_action; +---------------------+------------+----------+ | log_type | log_action | count(*) | +---------------------+------------+----------+ | pagetriage-curation | delete | 1132 | | pagetriage-curation | reviewed | 10913 | | pagetriage-curation | tag | 2170 | | pagetriage-curation | unreviewed | 134 | | pagetriage-deletion | delete | 1132 | | patrol | patrol | 31802 | +---------------------+------------+----------+ 6 rows in set (5.78 sec)
I appreciate the acknowledgement of failure. It's time for the community for an even braver move, let's take full control of Flow's development and get it to be actually usable.
Il 01/09/2015 23:26, Danny Horn ha scritto:
For a while now, the Collaboration team has been working on Flow, the structured discussion system. I want to let you know about some changes in that long-term plan.
While initial announcements about Flow said that it would be a universal replacement for talk pages, the features that were ultimately built into Flow were specifically forum-style group discussion tools. But article and project talk pages are used for a number of important and complex processes that those tools aren't able to handle, making Flow unsuitable for deployment on those kinds of pages.
To better address the needs of our core contributors, we're now focusing our strategy on the curation, collaboration, and admin processes that take place on a variety of pages. Many of these processes use complex workarounds -- templates, categories, transclusions, and lots of instructions -- that turn blank wikitext talk pages into structured workflows. There are gadgets and user scripts on the larger wikis to help with some of these workflows, but these tools aren't standardized or universally available.
As these workflows grow in complexity, they become more difficult for the next generation of editors to learn and use. This has increased the workload on the people who maintain those systems today. Complex workflows are also difficult to adapt to other languages, because a wiki with thousands of articles may not need the kind of complexity that comes with managing a wiki with millions of articles. We've talked about this kind of structured workflow support at Wikimania, in user research sessions, and on wikis. It's an important area that needs a lot of discussion, exploration, and work.
Starting in October, Flow will not be in active development, as we shift the team's focus to these other priorities. We'll be helping core contributors reduce the stress of an ever-growing workload, and helping the next generation of contributors participate in those processes. Further development on these projects will be driven by the needs expressed by wiki communities.
Flow will be maintained and supported, and communities that are excited about Flow discussions will be able to use it. There are places where the discussion features are working well, with communities that are enthusiastic about them: on user talk pages, help pages, and forum/village pump-style discussion spaces. By the end of September, we'll have an opt-in Beta feature available to communities that want it, allowing users to enable Flow on their own user talk pages.
I'm sure people will want to know more about these projects, and we're looking forward to those conversations. We'll be reaching out for lots of input and feedback over the coming months.
Danny Horn Collaboration team, PM _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sep 3, 2015, at 4:06 PM, Ricordisamoa ricordisamoa@openmailbox.org wrote:
I appreciate the acknowledgement of failure.
I don't think that's what was said at all. You may wish to re-read all of this.
--- Brandon Harris :: bharris@gaijin.com :: made of steel wool and whiskey
Il 04/09/2015 01:24, Brandon Harris ha scritto:
On Sep 3, 2015, at 4:06 PM, Ricordisamoaricordisamoa@openmailbox.org wrote:
I appreciate the acknowledgement of failure.
I don't think that's what was said at all. You may wish to re-read all of this.
Putting "active development" on hold when the software is little used in production and even some features a MVP should have had are missing, really sounds like a failure to me, although Danny has been very good at not making it sound like it. "To better address the needs of our core contributors", "we shift the team's focus to these other priorities", "communities that are excited about Flow discussions will be able to use it"
Brandon Harris ::bharris@gaijin.com :: made of steel wool and whiskey
The decision to stop Flow development could have been a matter of prioritizing resources, and a decision may have been made that many of the resources that would be invested in improving Flow can now be better used elsewhere.
I am reluctant to throw stones about Flow.
Pine
On 4 September 2015 at 01:38, Ricordisamoa ricordisamoa@openmailbox.org wrote:
Il 04/09/2015 01:24, Brandon Harris ha scritto:
On Sep 3, 2015, at 4:06 PM, Ricordisamoaricordisamoa@openmailbox.org wrote:
I appreciate the acknowledgement of failure.
I don't think that's what was said at all. You may wish tore-read all of this.
Putting "active development" on hold when the software is little used in production and even some features a MVP should have had are missing, really sounds like a failure to me, although Danny has been very good at not making it sound like it. "To better address the needs of our core contributors", "we shift the team's focus to these other priorities", "communities that are excited about Flow discussions will be able to use it"
It read to me and many others like a fairly standard set of euphemisms for when a project is killed but nobody wants to say "killed". Perhaps we're all reading it wrong.
So, non-euphemistically: could someone please detail what, precisely, is and is not the level of resource commitment to Flow? (And how it compares to e.g. the level of resource commitment to LQT.)
- d.
Re-reading the original email, it sounds to me like Flow is being put into maintenance mode, not killed. It also sounds to me like the resources that were being invested in Flow are going to be redirected to "the curation, collaboration, and admin processes that take place on a variety of pages. Many of these processes use complex workarounds -- templates, categories, transclusions, and lots of instructions -- that turn blank wikitext talk pages into structured workflows..."
As those of us who have spent a lot of time with these workflows know, they can be a time-consuming pain. (Does anyone else remember trying to track the discussion about the MediaViewer deployments to Commons, DEWP and ENWP over however many dozens of separate pages, at least three wikis, and multiple email threads?)
I think that Flow was intended to help with these situations. I guess that where it might be fair to say that Flow has been "killed" is in the sense that WMF seems to have decided that there are better options than Flow for addressing some of these workflow problems. It seems to me that the end goals are similar; the tools to achieve those goals may be different, and that's ok.
Pine
On Fri, Sep 4, 2015 at 12:24 AM, David Gerard dgerard@gmail.com wrote:
On 4 September 2015 at 01:38, Ricordisamoa ricordisamoa@openmailbox.org wrote:
Il 04/09/2015 01:24, Brandon Harris ha scritto:
On Sep 3, 2015, at 4:06 PM, Ricordisamoaricordisamoa@openmailbox.org wrote:
I appreciate the acknowledgement of failure.
I don't think that's what was said at all. You may wish tore-read all of this.
Putting "active development" on hold when the software is little used in production and even some features a MVP should have had are missing,
really
sounds like a failure to me, although Danny has been very good at not
making
it sound like it. "To better address the needs of our core contributors", "we shift the
team's
focus to these other priorities", "communities that are excited about
Flow
discussions will be able to use it"
It read to me and many others like a fairly standard set of euphemisms for when a project is killed but nobody wants to say "killed". Perhaps we're all reading it wrong.
So, non-euphemistically: could someone please detail what, precisely, is and is not the level of resource commitment to Flow? (And how it compares to e.g. the level of resource commitment to LQT.)
- d.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 9/4/15, Pine W wiki.pine@gmail.com wrote:
Re-reading the original email, it sounds to me like Flow is being put into maintenance mode, not killed. It also sounds to me like the resources that were being invested in Flow are going to be redirected to "the curation, collaboration, and admin processes that take place on a variety of pages. Many of these processes use complex workarounds -- templates, categories, transclusions, and lots of instructions -- that turn blank wikitext talk pages into structured workflows..."
As those of us who have spent a lot of time with these workflows know, they can be a time-consuming pain. (Does anyone else remember trying to track the discussion about the MediaViewer deployments to Commons, DEWP and ENWP over however many dozens of separate pages, at least three wikis, and multiple email threads?)
I seriously doubt any form of technology will solve the problem of independent groups with overlapping interests discussing things in multiple venues.
My reading of the original email is that they want to work on things that have rather fixed bureaucratic procedures (e.g. Discussions about what content to delete). Relatively free-form discussion across many locations, seems like the opposite of that imo. I would love to hear in more detail what the team concretely plans to work on, although I imagine that's still in the process of being planned.
-- -bawolff
Yes and no on the first point. Aggregation tools would be helpful. Admittedly it's rare to have discussions spill into so many venues, so ROI is questionable on an investment like that.
On more structured discussions, yes, those could be made easier to handle. Maybe it would be better to handle the easier cases first. I'm with you in looking forward to hearing plans for more details. (Maybe there can be a live discussion about this at WikiConference USA, with remote participation as an option?)
Pine
On Fri, Sep 4, 2015 at 1:25 AM, Brian Wolff bawolff@gmail.com wrote:
On 9/4/15, Pine W wiki.pine@gmail.com wrote:
Re-reading the original email, it sounds to me like Flow is being put
into
maintenance mode, not killed. It also sounds to me like the resources
that
were being invested in Flow are going to be redirected to "the curation, collaboration, and admin processes that take place on a variety of pages. Many of these processes use complex workarounds -- templates, categories, transclusions, and lots of instructions -- that turn blank wikitext talk pages into structured workflows..."
As those of us who have spent a lot of time with these workflows know,
they
can be a time-consuming pain. (Does anyone else remember trying to track the discussion about the MediaViewer deployments to Commons, DEWP and
ENWP
over however many dozens of separate pages, at least three wikis, and multiple email threads?)
I seriously doubt any form of technology will solve the problem of independent groups with overlapping interests discussing things in multiple venues.
My reading of the original email is that they want to work on things that have rather fixed bureaucratic procedures (e.g. Discussions about what content to delete). Relatively free-form discussion across many locations, seems like the opposite of that imo. I would love to hear in more detail what the team concretely plans to work on, although I imagine that's still in the process of being planned.
-- -bawolff
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, Sep 4, 2015 at 1:25 AM, Brian Wolff bawolff@gmail.com wrote:
I seriously doubt any form of technology will solve the problem of independent groups with overlapping interests discussing things in multiple venues.
My reading of the original email is that they want to work on things that have rather fixed bureaucratic procedures (e.g. Discussions about what content to delete). Relatively free-form discussion across many locations, seems like the opposite of that imo. I would love to hear in more detail what the team concretely plans to work on, although I imagine that's still in the process of being planned.
You're correct, as far as I know. I can't/won't speak for Danny about the product roadmap (I'm sure he will jump in here again), but one component of what's planned is indeed support for these so-called "bureaucratic procedures". I did some initial research before Wikimania (still-drafty wikipage report[1], internal presentation[2]), and Danny incorporated some of this into his Wikimania presentation.[3]
I've heard of several other components from the team, but "workflows" is definitely part of it.
Thanks to you, Pine, Risker and others for the good-faith assessments, btw.
J
1. https://www.mediawiki.org/wiki/Flow/Community_process_workflow_interviews_(J...) 2. https://www.mediawiki.org/wiki/File:Flow_workflow_interviews_-_initial_findi... 3. https://www.mediawiki.org/wiki/File:User(s)_Talk(ing)_-_Wikimania_2015.pdf
-- -bawolff
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Flow is going to be one of the extensions that the Collaboration team maintains, along with Echo and Thanks. "Not in active development" means that we're not going to build or change features, but we're going to fix bugs and make sure that people who are using Flow have a good experience with it.
It's a similar situation to Echo, which wasn't in active development for at least eighteen months, but we fixed bugs and made some changes to connect it up with Flow. We've recently started doing the prep work for global cross-wiki Echo notifications, which is another project that we're going to be working on in October.
We talked about the Workflows project at Wikimania, introducing it as something that we were going to work on in early 2016. This priority change basically means that Workflows moves from "3 to 6 months from now" to next month.
As people have noted, the Foundation spent money developing Flow discussion features, and we did the work in iterative stages, to make sure that there was a useable (if incomplete) product at every stage. That gave us the opportunity to get great feedback and see how people were using Flow, but it also just provides value on its own. Shifting priorities happens with product teams all the time, so you always want to be able to get to a stable place, and still have something worthwhile.
Right now, there are several wikis that are enthusiastic about using Flow, on user talk pages, help forums and village pump-style discussion pages. Later this month, we're going to release the opt-in beta feature for wikis that request it, so that people can turn Flow on for their own user talk pages, and continue to get value out of the existing product. At that point, it's our responsibility to fix bugs and maintain it, so that we're not jerking the rug out from under the people who have been so helpful and important to the team.
Danny
On Fri, Sep 4, 2015 at 9:07 AM, Jonathan Morgan jmorgan@wikimedia.org wrote:
On Fri, Sep 4, 2015 at 1:25 AM, Brian Wolff bawolff@gmail.com wrote:
I seriously doubt any form of technology will solve the problem of independent groups with overlapping interests discussing things in multiple venues.
My reading of the original email is that they want to work on things that have rather fixed bureaucratic procedures (e.g. Discussions about what content to delete). Relatively free-form discussion across many locations, seems like the opposite of that imo. I would love to hear in more detail what the team concretely plans to work on, although I imagine that's still in the process of being planned.
You're correct, as far as I know. I can't/won't speak for Danny about the product roadmap (I'm sure he will jump in here again), but one component of what's planned is indeed support for these so-called "bureaucratic procedures". I did some initial research before Wikimania (still-drafty wikipage report[1], internal presentation[2]), and Danny incorporated some of this into his Wikimania presentation.[3]
I've heard of several other components from the team, but "workflows" is definitely part of it.
Thanks to you, Pine, Risker and others for the good-faith assessments, btw.
J
https://www.mediawiki.org/wiki/Flow/Community_process_workflow_interviews_(J...) 2.
https://www.mediawiki.org/wiki/File:Flow_workflow_interviews_-_initial_findi... 3. https://www.mediawiki.org/wiki/File:User(s)_Talk(ing)_-_Wikimania_2015.pdf
-- -bawolff
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Jonathan T. Morgan Senior Design Researcher Wikimedia Foundation User:Jmorgan (WMF) https://meta.wikimedia.org/wiki/User:Jmorgan_(WMF) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Thanks for the expanded update.
I'm a big fan of Echo and am happy to hear that global notifications are coming.
If you'll be at WikiConference USA, I'd appreciate a chance to talk with you there in person, and others might as well!
Pine
On Fri, Sep 4, 2015 at 2:48 PM, Danny Horn dhorn@wikimedia.org wrote:
Flow is going to be one of the extensions that the Collaboration team maintains, along with Echo and Thanks. "Not in active development" means that we're not going to build or change features, but we're going to fix bugs and make sure that people who are using Flow have a good experience with it.
It's a similar situation to Echo, which wasn't in active development for at least eighteen months, but we fixed bugs and made some changes to connect it up with Flow. We've recently started doing the prep work for global cross-wiki Echo notifications, which is another project that we're going to be working on in October.
We talked about the Workflows project at Wikimania, introducing it as something that we were going to work on in early 2016. This priority change basically means that Workflows moves from "3 to 6 months from now" to next month.
As people have noted, the Foundation spent money developing Flow discussion features, and we did the work in iterative stages, to make sure that there was a useable (if incomplete) product at every stage. That gave us the opportunity to get great feedback and see how people were using Flow, but it also just provides value on its own. Shifting priorities happens with product teams all the time, so you always want to be able to get to a stable place, and still have something worthwhile.
Right now, there are several wikis that are enthusiastic about using Flow, on user talk pages, help forums and village pump-style discussion pages. Later this month, we're going to release the opt-in beta feature for wikis that request it, so that people can turn Flow on for their own user talk pages, and continue to get value out of the existing product. At that point, it's our responsibility to fix bugs and maintain it, so that we're not jerking the rug out from under the people who have been so helpful and important to the team.
Danny
On Fri, Sep 4, 2015 at 9:07 AM, Jonathan Morgan jmorgan@wikimedia.org wrote:
On Fri, Sep 4, 2015 at 1:25 AM, Brian Wolff bawolff@gmail.com wrote:
I seriously doubt any form of technology will solve the problem of independent groups with overlapping interests discussing things in multiple venues.
My reading of the original email is that they want to work on things that have rather fixed bureaucratic procedures (e.g. Discussions about what content to delete). Relatively free-form discussion across many locations, seems like the opposite of that imo. I would love to hear in more detail what the team concretely plans to work on, although I imagine that's still in the process of being planned.
You're correct, as far as I know. I can't/won't speak for Danny about the product roadmap (I'm sure he will jump in here again), but one component
of
what's planned is indeed support for these so-called "bureaucratic procedures". I did some initial research before Wikimania (still-drafty wikipage report[1], internal presentation[2]), and Danny incorporated
some
of this into his Wikimania presentation.[3]
I've heard of several other components from the team, but "workflows" is definitely part of it.
Thanks to you, Pine, Risker and others for the good-faith assessments,
btw.
J
https://www.mediawiki.org/wiki/Flow/Community_process_workflow_interviews_(J...)
https://www.mediawiki.org/wiki/File:Flow_workflow_interviews_-_initial_findi...
https://www.mediawiki.org/wiki/File:User(s)_Talk(ing)_-_Wikimania_2015.pdf
-- -bawolff
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Jonathan T. Morgan Senior Design Researcher Wikimedia Foundation User:Jmorgan (WMF) https://meta.wikimedia.org/wiki/User:Jmorgan_(WMF) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Also Corss-wiki watchlists https://phabricator.wikimedia.org/T5525 are good place to start.
Best
On Sat, Sep 5, 2015 at 2:35 AM Pine W wiki.pine@gmail.com wrote:
Thanks for the expanded update.
I'm a big fan of Echo and am happy to hear that global notifications are coming.
If you'll be at WikiConference USA, I'd appreciate a chance to talk with you there in person, and others might as well!
Pine
On Fri, Sep 4, 2015 at 2:48 PM, Danny Horn dhorn@wikimedia.org wrote:
Flow is going to be one of the extensions that the Collaboration team maintains, along with Echo and Thanks. "Not in active development" means that we're not going to build or change features, but we're going to fix bugs and make sure that people who are using Flow have a good experience with it.
It's a similar situation to Echo, which wasn't in active development for
at
least eighteen months, but we fixed bugs and made some changes to connect it up with Flow. We've recently started doing the prep work for global cross-wiki Echo notifications, which is another project that we're going
to
be working on in October.
We talked about the Workflows project at Wikimania, introducing it as something that we were going to work on in early 2016. This priority
change
basically means that Workflows moves from "3 to 6 months from now" to
next
month.
As people have noted, the Foundation spent money developing Flow
discussion
features, and we did the work in iterative stages, to make sure that
there
was a useable (if incomplete) product at every stage. That gave us the opportunity to get great feedback and see how people were using Flow, but it also just provides value on its own. Shifting priorities happens with product teams all the time, so you always want to be able to get to a stable place, and still have something worthwhile.
Right now, there are several wikis that are enthusiastic about using
Flow,
on user talk pages, help forums and village pump-style discussion pages. Later this month, we're going to release the opt-in beta feature for
wikis
that request it, so that people can turn Flow on for their own user talk pages, and continue to get value out of the existing product. At that point, it's our responsibility to fix bugs and maintain it, so that we're not jerking the rug out from under the people who have been so helpful
and
important to the team.
Danny
On Fri, Sep 4, 2015 at 9:07 AM, Jonathan Morgan jmorgan@wikimedia.org wrote:
On Fri, Sep 4, 2015 at 1:25 AM, Brian Wolff bawolff@gmail.com wrote:
I seriously doubt any form of technology will solve the problem of independent groups with overlapping interests discussing things in multiple venues.
My reading of the original email is that they want to work on things that have rather fixed bureaucratic procedures (e.g. Discussions
about
what content to delete). Relatively free-form discussion across many locations, seems like the opposite of that imo. I would love to hear in more detail what the team concretely plans to work on, although I imagine that's still in the process of being planned.
You're correct, as far as I know. I can't/won't speak for Danny about
the
product roadmap (I'm sure he will jump in here again), but one
component
of
what's planned is indeed support for these so-called "bureaucratic procedures". I did some initial research before Wikimania (still-drafty wikipage report[1], internal presentation[2]), and Danny incorporated
some
of this into his Wikimania presentation.[3]
I've heard of several other components from the team, but "workflows"
is
definitely part of it.
Thanks to you, Pine, Risker and others for the good-faith assessments,
btw.
J
https://www.mediawiki.org/wiki/Flow/Community_process_workflow_interviews_(J...)
https://www.mediawiki.org/wiki/File:Flow_workflow_interviews_-_initial_findi...
https://www.mediawiki.org/wiki/File:User(s)_Talk(ing)_-_Wikimania_2015.pdf
-- -bawolff
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Jonathan T. Morgan Senior Design Researcher Wikimedia Foundation User:Jmorgan (WMF) <https://meta.wikimedia.org/wiki/User:Jmorgan_(WMF)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Regarding specific resource-level commitments: I've always had a hard time with getting project-level financial data from WMF. I'm still waiting for replies to questions that I asked about the Annual Plan a couple of months ago. I do think that information like that should be public, and it would be nice if WMF would move toward more financial transparency that's at least on par with what's provided by US government agencies. I'd like to keep the financial transparency discussion a bit separate from the discussion about Flow's status. If WMF starts to provide public details about project-level accounting in general, I would welcome that.
Pine
On Fri, Sep 4, 2015 at 12:24 AM, David Gerard dgerard@gmail.com wrote:
On 4 September 2015 at 01:38, Ricordisamoa ricordisamoa@openmailbox.org wrote:
Il 04/09/2015 01:24, Brandon Harris ha scritto:
On Sep 3, 2015, at 4:06 PM, Ricordisamoaricordisamoa@openmailbox.org wrote:
I appreciate the acknowledgement of failure.
I don't think that's what was said at all. You may wish tore-read all of this.
Putting "active development" on hold when the software is little used in production and even some features a MVP should have had are missing,
really
sounds like a failure to me, although Danny has been very good at not
making
it sound like it. "To better address the needs of our core contributors", "we shift the
team's
focus to these other priorities", "communities that are excited about
Flow
discussions will be able to use it"
It read to me and many others like a fairly standard set of euphemisms for when a project is killed but nobody wants to say "killed". Perhaps we're all reading it wrong.
So, non-euphemistically: could someone please detail what, precisely, is and is not the level of resource commitment to Flow? (And how it compares to e.g. the level of resource commitment to LQT.)
- d.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I don't think putting a $$ value on it is necessary to answer David's question (Or even sufficient from a user perspective). The core of it is:
*Will anyone (from WMF) be coding any new features, that don't exist yet. *Will features that half work or are currently in the process of being developed, be completed (Assuming there are any, I'm not following flow development that closely). *Will someone be working on existing bugs during this time (Or at least existing bugs at some level of seriousness. And if so, what level of seriousness would be required for someone to do it) *Will someone be triaging and fixing new bugs as they come in (And again, how does the answer vary depending on the seriousness of the bug). *Is the team planning to come back to Flow at a later date in a serious way, or is this the end of active development for the foreseeable future.
-- bawolff
On 9/4/15, Pine W wiki.pine@gmail.com wrote:
Regarding specific resource-level commitments: I've always had a hard time with getting project-level financial data from WMF. I'm still waiting for replies to questions that I asked about the Annual Plan a couple of months ago. I do think that information like that should be public, and it would be nice if WMF would move toward more financial transparency that's at least on par with what's provided by US government agencies. I'd like to keep the financial transparency discussion a bit separate from the discussion about Flow's status. If WMF starts to provide public details about project-level accounting in general, I would welcome that.
Pine
It read to me and many others like a fairly standard set of euphemisms for when a project is killed but nobody wants to say "killed". Perhaps we're all reading it wrong.
So, non-euphemistically: could someone please detail what, precisely, is and is not the level of resource commitment to Flow? (And how it compares to e.g. the level of resource commitment to LQT.)
- d.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I'm speculating that an analogue for Flow's situation will be Echo's situation: somewhat maintained, but on the back burner for feature development. (Although I occasionally hear rumors of feature additions to Echo, and I think Echo might play well with improved discussion tools. I'd also like to see global watchlists and global notifications.) Hopefully we'll get a reply from Danny in the near future with more definitive answers about Flow's situation. (:
Pine
On Fri, Sep 4, 2015 at 1:34 AM, Brian Wolff bawolff@gmail.com wrote:
I don't think putting a $$ value on it is necessary to answer David's question (Or even sufficient from a user perspective). The core of it is:
*Will anyone (from WMF) be coding any new features, that don't exist yet. *Will features that half work or are currently in the process of being developed, be completed (Assuming there are any, I'm not following flow development that closely). *Will someone be working on existing bugs during this time (Or at least existing bugs at some level of seriousness. And if so, what level of seriousness would be required for someone to do it) *Will someone be triaging and fixing new bugs as they come in (And again, how does the answer vary depending on the seriousness of the bug). *Is the team planning to come back to Flow at a later date in a serious way, or is this the end of active development for the foreseeable future.
-- bawolff
On 9/4/15, Pine W wiki.pine@gmail.com wrote:
Regarding specific resource-level commitments: I've always had a hard
time
with getting project-level financial data from WMF. I'm still waiting for replies to questions that I asked about the Annual Plan a couple of
months
ago. I do think that information like that should be public, and it would be nice if WMF would move toward more financial transparency that's at least on par with what's provided by US government agencies. I'd like to keep the financial transparency discussion a bit separate from the discussion about Flow's status. If WMF starts to provide public details about project-level accounting in general, I would welcome that.
Pine
It read to me and many others like a fairly standard set of euphemisms for when a project is killed but nobody wants to say "killed". Perhaps we're all reading it wrong.
So, non-euphemistically: could someone please detail what, precisely, is and is not the level of resource commitment to Flow? (And how it compares to e.g. the level of resource commitment to LQT.)
- d.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Pine, given the questions at this point seem to be directed to the Collaboration team, with the intention of clarifying what their plans are, perhaps it would be best to encourage them to answer the questions rather than continue the speculation.
Danny, perhaps you could take the lead on responding to David Gerard's question?
On 4 September 2015 at 04:59, Pine W wiki.pine@gmail.com wrote:
I'm speculating that an analogue for Flow's situation will be Echo's situation: somewhat maintained, but on the back burner for feature development. (Although I occasionally hear rumors of feature additions to Echo, and I think Echo might play well with improved discussion tools. I'd also like to see global watchlists and global notifications.) Hopefully we'll get a reply from Danny in the near future with more definitive answers about Flow's situation. (:
Pine
On Fri, Sep 4, 2015 at 1:34 AM, Brian Wolff bawolff@gmail.com wrote:
I don't think putting a $$ value on it is necessary to answer David's question (Or even sufficient from a user perspective). The core of it is:
*Will anyone (from WMF) be coding any new features, that don't exist yet. *Will features that half work or are currently in the process of being developed, be completed (Assuming there are any, I'm not following flow development that closely). *Will someone be working on existing bugs during this time (Or at least existing bugs at some level of seriousness. And if so, what level of seriousness would be required for someone to do it) *Will someone be triaging and fixing new bugs as they come in (And again, how does the answer vary depending on the seriousness of the bug). *Is the team planning to come back to Flow at a later date in a serious way, or is this the end of active development for the foreseeable future.
-- bawolff
On 9/4/15, Pine W wiki.pine@gmail.com wrote:
Regarding specific resource-level commitments: I've always had a hard
time
with getting project-level financial data from WMF. I'm still waiting
for
replies to questions that I asked about the Annual Plan a couple of
months
ago. I do think that information like that should be public, and it
would
be nice if WMF would move toward more financial transparency that's at least on par with what's provided by US government agencies. I'd like
to
keep the financial transparency discussion a bit separate from the discussion about Flow's status. If WMF starts to provide public details about project-level accounting in general, I would welcome that.
Pine
It read to me and many others like a fairly standard set of euphemisms for when a project is killed but nobody wants to say "killed". Perhaps we're all reading it wrong.
So, non-euphemistically: could someone please detail what, precisely, is and is not the level of resource commitment to Flow? (And how it compares to e.g. the level of resource commitment to LQT.)
- d.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org