New subject: Clarifying role of different Wikidata extensions (Re: Loading DataTypes in WMF config)

27 Aug 2013

Hi Denny,

On Tue, Aug 27, 2013 at 4:27 AM, Denny Vrandečić <
denny.vrandecic(a)wikimedia.de&gt; wrote:
...
  2013/8/27 Rob Lanphier &lt;robla(a)wikimedia.org&gt;
  On Mon, Aug 26, 2013 at 9:26 AM, Denny Vrandečić
 &lt;denny.vrandecic(a)wikimedia.de&gt; wrote:
  We are indeed not yet using the RFC process, but
I would prefer if we
 could
 agree to move to this process in the future, as this particular
 discussion
 is going on already a bit longer than what I would expect for a
 discussion
 regarding the question about how to organize code. 

 This is not just about how we organize code. This is about how we
 package our work. It's unusual for us to have extensions with hard
 dependencies on other extensions, let alone the complicated hierarchy
 you all have chosen. It may be ok to do that, but we should discuss
 it before setting the precedent.

 This was already discussed here:
 <http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg69983.html> 
Yes, it was discussed. I was traveling the week that thread broke out, and
never fully caught up on that particular thread (only fully read it this
morning), so my apologies.

That said, it didn't appear to me that we actually resolved anything there.
Did I miss something?

...
  Scribunto and Babel are other extensions that have
dependencies, and there
 are more of them. We are not setting a sole precedent here. 
Scribunto has optional integration with WikiEditor, SyntaxHighlight GeSHi,
CodeEditor. The latter three all are useful extensions to end users in
their own right, and Scribunto works fine without them. Moreover, I'm
comfortable that I could walk around the office and get a coherent and
mostly correct explanation about what all of these extensions do from many
(if not most) developers here.

I'm not as familiar with the dependencies that Babel has. In my cursory
look, the situation looks similar to Scribunto's dependencies. The
description for Babel could be a bit better, but it's sufficient for me to
know what end-user functionality it's providing.

I'm not saying that, because we haven't really managed dependencies between
internal libraries before that we can't do it now. However, I don't think
your examples support your case that this is already standard practice.

...
   This gets
exposed to end users via Special:Version:
 https://en.wikipedia.org/wiki/Special:Version

 Since MediaWiki administrators often use this as a means of
 understanding how to configure their wikis "like Wikipedia", it would
 be nice if we didn't clutter that page up with a lot of the internals
 of our systems. Each of the links should point to a page that does a
 good job of describing what the extension does, and the vast majority
 of them do. Unfortunately, for most of the Wikidata extensions right
 now, the pages are pretty much boilerplaite plus a one-liner in many
 cases.

 I just checked a random sample of other extensions, and most of them are
 just boilerplate plus a one-liner. I just started at the bottom:
 <https://www.mediawiki.org/wiki/Extension:ZeroRatedMobileAccess>
 <https://www.mediawiki.org/wiki/Extension:WikimediaMessages>
 <https://www.mediawiki.org/wiki/Extension:WikimediaShopLink> 
Starting at the bottom isn't a representative sample. Moreover, the
documentation for ZeroRatedMobileAccess is mostly in the clearly linked
README which is not the worst place for it.

Most of the spot checking I did on other extensions, there was sufficient
information there for me to understand the essential functionality provided.

...
  Also, this is a very different point than raised
before, and we have, in
 several places tried to improve our documentation, as e.g. by creating this
...
  page:
 <https://www.mediawiki.org/wiki/Wikibase>
 But the quality of our documentation seems to be a shift in the focus of
 this discussion. I would be happy if we could define well what the actual
 point of discussion is, so that we can resolve it as soon. 
I'm trying to understand the breakup of the extensions, and in our
continuing discussion, you've pointed me at varying bits of documentation
that don't answer the questions that I have.

I'd like to understand what exactly is so terrible about the status quo
that you all are blocked on your development.  If this refactoring is
really so urgent, why can't you clearly and concisely state not only what
you are doing, but *why* you are doing it.

...
   Rather than
get too far into the implementation details of what your
 extensions are doing, I think maybe I'll hold off until someone on my
 team has more time to think about this and comment on it.

 As long as this does not contradict your other mail, where we said not to
 further delay the refactoring of the DataValues-related extensions, sure. 
Well, we can move forward with this specifically:
https://gerrit.wikimedia.org/r/#/c/76481/

I would hope you can hold off on the other refactoring until there is at
least one person on my team who can confidently explain what the role of
each of the extensions you're proposing is. I was going to bite the bullet
and just get my head around it myself, but I need to be realistic about the
level of effort I can expend with this.

Rob

Re: [Wikidata-tech] Clarifying role of different Wikidata extensions (Re: Loading DataTypes in WMF config)