Hi Denny,
On Tue, Aug 27, 2013 at 4:27 AM, Denny Vrandečić < denny.vrandecic@wikimedia.de> wrote:
2013/8/27 Rob Lanphier robla@wikimedia.org
On Mon, Aug 26, 2013 at 9:26 AM, Denny Vrandečić denny.vrandecic@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
Hi Rob,
sorry for the longer wait on this one.
2013/8/28 Rob Lanphier robla@wikimedia.org
On Tue, Aug 27, 2013 at 4:27 AM, Denny Vrandečić < denny.vrandecic@wikimedia.de> wrote:
This was already discussed here: <
http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg69983.html%3E
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?
No, this is correct. The question was not resolved. I just want to avoid to be blocking on resolving this question.
It would indeed be helpful to actually resolve the question in order not to keep hitting on it repeatedly, but I do not know how to have a decision on this topic in an effective time frame, which is why I didn't take the lead on resolving this.
Scribunto and Babel are other extensions that have dependencies, and
there
are more of them. We are not setting a sole precedent here.
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.
Sorry, the examples have been sloppy (I should not trust my memory!). Translate extension depends on ULS, CodeEditor depends on WikiEditor, Semantic Result Formats depends on Semantic MediaWiki. My bad.
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.
The breakup of extensions is mostly guided to avoid unnecessary dependencies, e.g. to avoid that because Extension:Maps depends on Extension:ParamProcessor and Extension:ParamProcessor on Extension:DataValues, suddenly have Extension:Maps a dependency on the implementation of the time value parser. This has been the major guiding principle in the way the extensions have been broken down.
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.
That is actually simpler to answer: it is blocking the release of a number of extensions who depend on the DataValues extensions. We would like to perform the break up, reduce the number of components with that, and have a more stable separation in components before these extensions can see their releases. The former breakup had its deficiencies, after working with it for a year we have developed a better understanding of how it should be done, and we would like to fix that, by reducing the number of components and increasing cohesion.
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.
I would hope that we could do the whole DataValues refactoring first, and
then have the step you describe for further work.
I would like to have this person to be assigned soonish, and also to get sufficient time for this task. And thank you for this offer, the outcome should be a greatly improved documentation of our components.
There are further refactorings that I want to see happen: I want the EntitySelector jQuery widget to be moved out of Wikibase, for example, and I will put effort into handling this better. I really didn't expect that this question would rise so many questions, and it is my mistake to not give more attention to this.
Rob
Cheers, Denny
(Sorry for sending this mail on the last minute before the weekly call, and no, I do not expect you to have it read in time for it :) )
wikidata-tech@lists.wikimedia.org