On 26/06/15 21:21, Quim Gil wrote:
Note that probably the complementary side of your frustration is the
frustration of designers and others trying to improve Wikimedia and its
projects, only to find a strong resistance to change almost every time that
fresh ideas are proposed. In our case here, currently we are not very
successful at attracting third party developers to use our APIs, definitely
not at the scale that one would expect considering Wikipedia's relevance.
We welcome ideas and help from people willing to solve this problem. We are
happy to take risks trying solutions, even if that means that we will make
some mistakes along the way.

It should perhaps be noted that this seems a continuation on a general trend to avoid learning how to work with the communities and existing designs. It may be faster and less frustrating to simply sod off and do something new somewhere else, but this does not solve the existing problems - all it does is introduce more inconsistencies and more things that need to be consolidated later, if they survive at all. Except they usually don't, because ignoring what people do and use and expect does not lead to practical designs, it leads to things people don't use, maintain, or contribute to, which brings us back in part to the technical debt associated with having so many different wikis.

But when it comes to working with what already exists, I know from experience that this is far from easy, and in fact often incredibly frustrating in practice. Thing is, though, we have to - the existing products need to be worked with in order to move forward. That's just how it is.

As we tend to say about the unsolicited redesigns of (en) wikipedia, it's always a lot easier when you don't have to design with reality as a constraint. There's a reason we never use any of them.

-I

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to