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