Hi Denny,
On Tue, Aug 27, 2013 at 4:27 AM, Denny Vrandečić <
denny.vrandecic(a)wikimedia.de> wrote:
2013/8/27 Rob Lanphier <robla(a)wikimedia.org>
On Mon, Aug 26, 2013 at 9:26 AM, Denny Vrandečić
<denny.vrandecic(a)wikimedia.de> 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