On Tue, Aug 27, 2013 at 4:27 AM, Denny Vrandečić <email@example.com> wrote:
> 2013/8/27 Rob Lanphier <firstname.lastname@example.org>
>> On Mon, Aug 26, 2013 at 9:26 AM, Denny Vrandečić
>> <email@example.com> 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:
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:
>> 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
> 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:
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
> 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:
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.