Interesting. What I'm noticing in both this discussion and the
discussions around MV is that a lot of us think that the solution has
value, but the features are not prioritized well. I don't have much
experience with Trello, but I know of lots of other tools (Bugzilla is
one, I believe) that can support discussions from the community per
feature/bug and have a "voting" feature.

I don't support RfC's on full systems. If we get to this point we've
all been doing it wrong for far too long to have an easy fix. But I
think that RfC-like discussions on every individual feature make a lot
of sense. And I think that one of the biggest steps the WMF can take
is to base prioritization of features on such "RfC"'s in a
well-defined and well-understood way. IMO, user studies are important,
but they'd be better used to '''convince''' the community that
something is useful from a perspective that may be very different from
a very experienced user's, rather than force features down our
throats.

I know that this is already happening to some degree. But is the WMF
'''obligated''' to prioritize features based on community feedback?

As a separate question, would we find it easier to do this onwiki, and
are there extensions that we can build with the WMF to facilitate such
discussions and feature management? Or we cool with the tools we
already have?

,Wil

On Fri, Sep 5, 2014 at 10:58 AM, Risker <risker...@gmail.com> wrote:
> I think there have been some pretty strong indications over the years that
> the current talk page system needs to be improved.  However, there's been
> little discussion at all about whether Flow is that improvement.  I have
> been following the development for quite a while, and it really looks like
> the system was developed backwards: essential functions for effective
> discussion that already exist and are used on a daily basis were not
> included in the initial designs, while the design incorporated plenty of
> bells and whistles that were considered desirable (although the reasons for
> desirability weren't necessarily universally held or particularly clear).
> This has resulted in a huge amount of re-engineering to incorporate (some
> of the) needed functions , and a lot of downplaying of the feedback given
> because the feedback has conflicted with the "bells and whistles" of the
> original design.  There is also the fact that it would add another
> completely different user interface to the editing process, which increases
> barriers for existing users but even more so for new users.
>
> In other words, the issues with Flow are so deeply rooted in its core
> design and philosophy that it may not be possible to come up with a product
> that is actually useful on the projects we have to replace the discussion
> system we have.  It seems that the Flow team has assembled the ingredients
> to make a chocolate cake with the hope that it will be a suitable
> replacement for vegetable stew.
>
> Risker/Anne

_______________________________________________
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Reply via email to