I want to address Isarra's feedback (below), but before let me complete S's reply to Brian.
On Mon, Jul 6, 2015 at 7:41 AM, Brian Wolff <bawo...@gmail.com> wrote: > In essence, this is an advertisement aimed at programmers not > associated with the Wikimedia movement, to use various Wikimedia APIs > in their programming projects that are unrelated to Wikimedia. In a > sense, targeting these programmers as a distinct group of users, and > trying to convince them to use our "product". > > Is that right? If it isn't, may I suggest that this should be the > intended purpose? > This is the intended purpose, yes. The rest of your reply is spot on. Comments: If so, I think the content of the developer hub should have a little > bit of a different focus. It should concentrate on things that make us > unique, and things that are likely to have wide applicability and > value outside of Wikimedia. > Yes. We have been underestimating the importance of looking at our APIs with external eyes. We are so used to look at our own use cases, and so do most of the developers S relies on to document APIs. Proposals for projects / people we should contact and interview to gather ideas are welcome. (Also, the name is very confusing. After more than a year we haven't solved the problem of finding a clean association with "developer" for the many reasons many people have provided. It has been proven difficult to add the "data" aspect too. The feedback received after the announcement of the prototype confirms this problem. As a solution, I'm proposing to focus on the Api aspect, improving the Api: namespace in mediawiki..org and finding a project name that stresses the Api aspect. Once the discussion about the namespace at https://www.mediawiki.org/wiki/Thread:Project:Current_issues/Adding_a_dev_namespace_for_%22Data_and_developer_hub%22_articles/reply_(18) is resolved, we will rename the project accordingly. The very fact that in > [[mw:dev.wikimedia.org]], it states its not for MediaWiki "hackers" > despite the fact that in our community (And particularly in the larger > Wikimedia community), "developer" as a word is much more commonly used > than the word "hacker" is, for what the document means by "hacker", > should attest to the confusingness of the nomenclature). > Yes, yes, edited. In particular the proposed persona's suggest a different target than > what I commented above. Also agreed, and as soon as the namespace discussion is clear, we will update those personas accordingly. The more we got into details, the clearer it has been that we should narrow the focus of this project. Let's produce something interesting and useful for those third party developers that could use our web Apis in their own projects. We also need to make happy the other personas, but one step at a time. On Thu, Jul 2, 2015 at 9:15 PM, Isarra Yos <zhoris...@gmail.com> wrote: > 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. The problem I have with this reasoning is that we are not proposing a different skin for Wikipedia. The design of this site doesn't need to be efficient for the multiple use cases and the heavy legacy of Wikipedia. There is more than Vector out there. We can allow ourselves to experiment with something fresh, and then fine tune or revert. Vector is the skin powering Wikipedia and hundreds of Wikimedia sites (and more), and for this reason changing anything there takes a lot of effort discussing and implementing (see Winter, and see several other projects that took so much time and brought so little changes to our users). We don't have design resources for this project, but we don't want to renounce to bring a fresh look to it. We are recycling a skin that already existed, we are filing bugs, and then Prateek, S, and maybe others contribute whenever they have time, motivated by their willingness to see that fresh look arriving to users. It is not strange to find developer sites not following the user experience of their super-popular products. This gives them freedom from the "product people" and this allows them to focus on the specific purpose and audience of their developer sites. Having a skin deployed in mediawiki.org that looks contemporary and not-like-Vector, not-like-Wikipedia cannot be harmful. As said, the worse that can happen is that we must revert and fallback to Vector. Fine, at least we can say that we tried. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
