Hi folks,
Bryan and I had an etherpad editing session, and rewrote the wiki page for the project: https://www.mediawiki.org/wiki/Library_infrastructure_for_MediaWiki
Please aggregate your ideas there, or on the talk page.
Summary of my response to Bryan: * Structured logging should be the first project * This project will probably get a lot of visibility soon enough * ResourceLoader as a library? * Docs can live on wiki * Bryan is awesome
More comments inline:
On Mon, Sep 29, 2014 at 11:07 PM, Bryan Davis bd808@wikimedia.org wrote:
I know that I want to finish the logging work. I think this can be used as a good example of how to consume external libraries in MediaWiki core as well as helping solve a real deficiency in our existing code base.
Yup, I think this makes sense, and that seems to be the conclusion from our conversation on Monday. Let's roll with this.
My RFC on the topic is a good start but the processes and procedures outlined there need to be published in a more visible place on wiki and battle tested for deficiencies.
Agreed. The wiki page we have now is probably workable for this purpose, but we may want to actually have an RFC to make this even more visible. That said, I think if this ends up a top 5 priority, it'll get plenty of visibility.
I think I'd also like to see the Profiler work done as I've heard that many components in MediaWiki are basically only tied to logging and profiling. I'm totally willing to be persuaded that there is a better candidate for extracting into a library however. One question I'd like to ask is "what functionality from MediaWiki do you miss when you write a standalone PHP app?" Database? Caching? I18n bits and pieces? Is one of these more compelling for extracting and publishing than the profiler?
The idea that Bryan and I discussed as we were writing this up was ResourceLoader, since it's one of the more obviously useful external components. It'd be quite an undertaking though, and would be a stretch goal without significant help from Roan and Timo.
I'd also like to hear ideas about how we should be documenting the
extracted libraries. Should we have a different workflow for generating docs from code? Is publishing docs as wiki pages a good, bad or meh idea?
I think generally pointing people at our wiki for full documentation is probably fine for now, and is probably going to work as a long-term strategy. We should revisit this in a few months if it seems to be failing in any way.
If we don't document on wiki how can we encourage
document contributions from casual users? If we do document on wiki how can we ensure that changes in the API are propagated to the documentation soon after merge? How important is localization for code documentation?
What sort of in-tree documentation would you feel is necessary? Seems to me having relatively minimal in-tree documentation combined with richer on-wiki documentation could be reasonably effective.
In case you are wondering "who put Bryan in charge here?", the answer is RobLa. :) Following in the model of the HHVM project where Ori has been acting as project manager / product owner, RobLa has tapped me to take the lead on organizing the library infrastructure project if it gets green lighted. I'll need a lot of help since I still don't know as much about MediaWiki itself as our average 13 year old contributor, but I hope I can be of service with my experience in project and product management.
As always, Bryan is selling himself short. :-) Bryan has been an effective advocate for doing this work, and it's great to see it get traction in the wider org.
Rob