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 <[email protected]> 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
_______________________________________________ MediaWiki-Core mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mediawiki-core
