A new wiki page is born:
https://www.mediawiki.org/wiki/Upstream_projects
Please help listing the right projects, adding their contacts and links. The idea is to get a clear picture of the upstream projects we rely on, and also of the people in our community that know best about them.
The page has three sections that correspond to different types of upstream:
* projects we develop that we want others to use and contribute to (e.g. MediaWiki) * projects others develop and we embed in our architecture (e.g. Elasticsearch) * projects others develop and we embed in our processes (e.g. Jenkins)
These projects define our location in the free software map. The health of our projects depends on their own health, and also on the health of our common links.
Currently we rely in the knowledge and contacts of official and unofficial maintainers of these tools, who are frequently members of these upstream communities by their own initiative. If you are one of them, you probably see the usefulness of documenting these links.
Quim,
On Tue, Mar 18, 2014 at 10:47:04AM -0700, Quim Gil wrote:
- projects we develop that we want others to use and contribute to (e.g.
MediaWiki)
- projects others develop and we embed in our architecture (e.g. > Elasticsearch)
- projects others develop and we embed in our processes (e.g. Jenkins)
These projects define our location in the free software map. The health of our projects depends on their own health, and also on the health of our common links.
I'm not sure what "embed in our architecture" or "embed in our processes" means, could you clarify that?
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). 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.
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.
Regards, Faidon
On Tue, Mar 18, 2014 at 6:08 PM, Faidon Liambotis faidon@wikimedia.org wrote:
On Tue, Mar 18, 2014 at 10:47:04AM -0700, Quim Gil wrote:
- projects we develop that we want others to use and contribute to (e.g.
MediaWiki)
- projects others develop and we embed in our architecture (e.g. > Elasticsearch)
- projects others develop and we embed in our processes (e.g. Jenkins)
These projects define our location in the free software map. The health of our projects depends on their own health, and also on the health of our common links.
I'm not sure what "embed in our architecture" or "embed in our processes" means, could you clarify that?
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). 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.
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.
Hi Faidon,
Quim made this list in the interest of making us a better collaborator in the free software ecosystem. Here's what today looks like: * WMF developers work primarily on MediaWiki, with limited participation in other software we rely on. We have reasonably robust participation outside participation, but WMF contributors dominate the development * The makers of other software we rely on take a mild interest in the use of their software on our sites. * Outside of MediaWiki, there is very little interest in the other software produced by WMF
Here's what success looks like * WMF developers work on a suite of integrated components, some of which WMF is the upstream, and some of which aren't. For most components, WMF developers do not dominate development, and Wikimedia sites are a big use case, but not the only use case * Many popular software projects led by non-WMF employees consider the Wikimedia's use their flagship use case, perhaps even working with us to deploy the latest versions of their software to our site as a means of more quickly getting real-world use of their software. * New WMF projects (beyond MediaWIki and components of MediaWiki) frequently get traction beyond Wikimedia sites and beyond MediaWiki-specific usage
Some of the above may look scary (e.g. do we really want outside projects to be deployed like MediaWiki is today?), but we're going to have to be clever to scale up our development to meet the need of building a truly modern website, short of hiring as many developers as Facebook, Google, Twitter, etc have.
Assuming this is true, the real questions implicit in Quim's list are: * Which projects are the most important to foster a better upstream relationship with? * Which projects are we the upstream provider?
One way of filtering this list is look at the projects for which we've already developed some sort of upstream relationship. Nik is submitting a lot of work upstream to ElasticSearch, so that's why that makes the cut. Faidon, I'm guessing Debian should be on that list. OpenStack probably deserves a mention. Perhaps there are projects that we currently don't collaborate with the upstream, but there would be big benefit for us in doing so. We don't need to get every obscure command line utility that runs on the cluster, but let's identify some high-value targets of upstream collaboration, and get them on the list.
Thanks Rob
On 03/18/2014 09:08 PM, Faidon Liambotis wrote:
I'm not sure what "embed in our architecture" or "embed in our processes" means, could you clarify that?
Only Quim can clarify what he means, of course, but I read the distinction as "is used for actually producing output" vs. "we use it for our daily work".
For instance, "apache" is part of our architecture, "git" is part of our processes.
Quim, am I understanding you correctly?
-- Marc
Dunno if it's still the case, but back when I was working in fundraising we collaborated a lot and with the CiviCRM community and contributed a bit back to the project (both in terms of code as well as hosting CiviCRM meetups). Drupal too, although to a lesser extent. Perhaps someone currently working in fundraising can confirm if that's still the case.
On Wed, Mar 19, 2014 at 11:06 AM, Marc A. Pelletier marc@uberbox.orgwrote:
On 03/18/2014 09:08 PM, Faidon Liambotis wrote:
I'm not sure what "embed in our architecture" or "embed in our processes" means, could you clarify that?
Only Quim can clarify what he means, of course, but I read the distinction as "is used for actually producing output" vs. "we use it for our daily work".
For instance, "apache" is part of our architecture, "git" is part of our processes.
Quim, am I understanding you correctly?
-- Marc
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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).
wikitech-l@lists.wikimedia.org