Hi,
On Tuesday, March 18, 2014, Faidon Liambotis faidon@wikimedia.org wrote:
I'm not sure what "embed in our architecture" or "embed in our processes" means, could you clarify that?
I have just edited the wiki page to be more precise:
Components Projects that contribute to the architecture of MediaWiki, key extensions, and applications. They are included in the downloadable packages of key Wikimedia projects, or they are identified as required dependencies.
Tools Projects that contribute to our development process. They are installed in Wikimedia servers and they are used in the release process of key Wikimedia projects.
I see for example that the page has a lot of the shiny stuff (e.g. Lua
is there, but bash/PHP/Python/Ruby are not).
You could have said "I'm impressed about the number of projects listed by 14 unique editors in just a few hours!" ;)
PHP/Python/Ruby already appear multiple times in the Languages column, showing their relevance to our project from this perspective. They can also be listed as upstream projects, of course.
Moreover, a few random
libraries are there but others that we take for granted are not (e.g. librsvg is there, but noone thought of gzip or bzip2; unihan vs. all of the dozens of fonts that we use, etc.). Not to mention all the hundreds of absolutely essential tools that we use for system maintenance that noone ever sees or cares about, from Linux to GNU sed, dpkg, apt etc.
I think this needs to be clarified and/or scoped a bit better, including explaining the rationale & motivation behind doing all this work.
Good questions, helpful to edit that page further. Now it says
Motivation
This is a first step to improve our relations with other communities, to increase the contributions received, and our influence in the projects that matter to us.
Our mid term goals include:
* identify the projects where we want to see significant development, to the point of sending patches as well * identify the communities where Wikimedia should be regularly active and heard * identify the people in the Wikimedia and upstream communities that know each other and act as bridge * identify organizations and events we should get in touch and be part of * get involved in bigger development efforts regularly, become a regular FOSS player
For what it's worth, a uniqued dpkg -l across the production
infrastructure shows 3276 software packages and personally I'd have a very hard time filtering the list based on what fits in the above description.
While we don't have an algorythm to calculate the relevance of an upstream project yet, we do have an opinion about some components where our attention is more required than others, even if both are essential, based on how reliable they are, whether we miss features or not, whether the upstream maintainers are responsive or not...
While we have "Bug 51555 - librsvg seems unmaintained", dpkg is probably doing fine without our specific attention. So far we are relying on human memories and perhaps arcane resources to know which components matter and who knows more. 3276 upstream packages means that we need a curated list telling us a bit more about the communities maintaining the packages that we would like to improve or see improved.
Sorry for not making these points clearer before. I hope it helps improving that page further.
Thank you for the quick feedback pointing to the right directions (as usual in Faidon).