Collaboration team reprioritization

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Collaboration team reprioritization

Danny Horn
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Collaboration team reprioritization

Pine W
Thanks for the update. Discussion is taking place on Wikimedia-l.

Pine
On Sep 1, 2015 2:27 PM, "Danny Horn" <[hidden email]> 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Collaboration team reprioritization

Federico Leva (Nemo)
In reply to this post by Danny Horn
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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Collaboration team reprioritization

Dan Garry
On 1 September 2015 at 23:21, Federico Leva (Nemo) <[hidden email]>
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

--
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Collaboration team reprioritization

Florian Schmidt
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 <[hidden email]>
An: Wikimedia developers <[hidden email]>

On 1 September 2015 at 23:21, Federico Leva (Nemo) <[hidden email]>
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

--
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Collaboration team reprioritization

David Gerard-2
In reply to this post by Dan Garry
On 2 September 2015 at 07:27, Dan Garry <[hidden email]> wrote:
> On 1 September 2015 at 23:21, Federico Leva (Nemo) <[hidden email]>
> 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.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Collaboration team reprioritization

Risker
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
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Collaboration team reprioritization

David Gerard-2
On 2 September 2015 at 14:51, Risker <[hidden email]> 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.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Collaboration team reprioritization

Roan Kattouw-3
In reply to this post by Risker
On Wed, Sep 2, 2015 at 6:51 AM, Risker <[hidden email]> 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%28ing%29_-_Wikimania_2015.pdf&page=8


>   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.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Collaboration team reprioritization

Roan Kattouw-2
In reply to this post by David Gerard-2
On Wed, Sep 2, 2015 at 6:21 AM, David Gerard <[hidden email]> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Collaboration team reprioritization

Amir Sarabadani-2
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 <[hidden email]> wrote:

> On Wed, Sep 2, 2015 at 6:21 AM, David Gerard <[hidden email]> 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Collaboration team reprioritization

Roan Kattouw-2
In reply to this post by Roan Kattouw-2
On Wed, Sep 2, 2015 at 11:20 AM, Roan Kattouw <[hidden email]>
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.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Collaboration team reprioritization

Matthew Flaschen-2
In reply to this post by David Gerard-2
On 09/02/2015 12:35 PM, David Gerard wrote:

> On 2 September 2015 at 14:51, Risker <[hidden email]> 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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Collaboration team reprioritization

Matthew Flaschen-2
In reply to this post by David Gerard-2
On 09/02/2015 09:21 AM, David Gerard wrote:

> On 2 September 2015 at 07:27, Dan Garry <[hidden email]> wrote:
>> On 1 September 2015 at 23:21, Federico Leva (Nemo) <[hidden email]>
>> 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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Collaboration team reprioritization

Matthew Flaschen-2
In reply to this post by Federico Leva (Nemo)
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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Collaboration team reprioritization

S Page-3
In reply to this post by Federico Leva (Nemo)
1. Regarding Flow and LQT on mediawiki.org:

On Tue, Sep 1, 2015 at 11:21 PM, Federico Leva (Nemo) <[hidden email]>
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_namespace_for_%22Data_and_developer_hub%22_articles
.
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 !

--
=S Page  WMF Tech writer


[1] > The main goals for the Flow project are:

   - to make the wiki discussion system **more accessible for new users**
   - to make the wiki discussion system **more efficient for experienced
   users**
- to encourage **meaningful conversations** that support collaboration
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Collaboration team reprioritization

Federico Leva (Nemo)
In reply to this post by Matthew Flaschen-2
 > 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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Collaboration team reprioritization

Brian Wolff
In reply to this post by Danny Horn
> 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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Collaboration team reprioritization

Oliver Keyes-4
On 3 September 2015 at 07:44, Brian Wolff <[hidden email]> 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



--
Oliver Keyes
Count Logula
Wikimedia Foundation

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Collaboration team reprioritization

Matthew Flaschen-2
In reply to this post by Federico Leva (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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
12