Talk:Upstream projects

Possible "Invented Here" entries

Wikimedia upstream projects

Name & URL	Description	Language(s)	Repository	Bug tracker	Main contacts
…
ResourceLoader	Web code delivery system	PHP	Currently embedded inside MW	Bugzilla	Timo Tijhof, Trevor Parscal, Roan Kattouw
OOjs	Library for working with objects	Javascript	Git	Bugzilla	Timo Tijhof, Roan Kattouw
OOjs UI	OOjs-based UX toolkit	Javascript	Git	Bugzilla	Timo Tijhof, Trevor Parscal
VisualEditor	Rich HTML editor	Javascript	Git	Bugzilla	James Forrester, Trevor Parscal, Roan Kattouw

Jdforrester (WMF) (talk) 18:05, 18 March 2014 (UTC)

We have a pile of such Components as well for Wikibase. (Wikibase Components) Not sure it makes all that much sense to maintain a copy of the list though. --Jeroen De Dauw (talk) 19:25, 18 March 2014 (UTC)

Need clarificatrion

Our developer community relies on several upstream projects delivering software that we embed in our architecture or our processes.

Does this mean "WMF", "MW core", "WMF + anything MediaWiki", or something else?

At the same time, our community develops software projects used by others, for which we are their upstream.

So all things that depend on MediaWiki should be listed? That's a lot of stuff... Also, not sure where this fits on the page.

--Jeroen De Dauw (talk) 19:25, 18 March 2014 (UTC)

I also don't understand what's the difference between this and Bug_management/Upstream_bugtrackers. --Nemo 20:17, 18 March 2014 (UTC) P.s.: There is some language stuff that I listed on ohloh.[1]

I've also linked some more ohloh projects I created. The pieces of software (beyond MediaWiki extensions) created by "us" are in the hundreds or thousands. I think ohloh is a better place where to catalogue them and it's hard enough even there. I have no idea what would fit here.

Speaking of which, I'd like someone to play with (existing) mediawiki2git tools to bring all CSS/JS pages of Wikimedia projects into a git repo and see what ohloh gets out of it. :) --Nemo 08:36, 15 April 2014 (UTC)

Unless there are objections I'll merge Bug management/Upstream bugtrackers into this. --Nemo 16:53, 25 August 2014 (UTC)

@Nemo bis: That seems to confuse matters; that page is a listing of bug trackers for upstreaming bug reports, this page is to give credit, which has been morphed into a hodge-podge mess of a page with tables rather than credit. Instead, we should revert the destructive changes and turn this back into more of a narrative. Jdforrester (WMF) (talk) 17:40, 25 August 2014 (UTC)

This page is to give credit? Since when? That was never stated. What I see since day 1 is a list of pointers to repositories, issue trackers and contacts in order to enable communication and contribution. Be bold and edit yourself: the edits to revert according to your description would be everything but the very first so I would not know how to implement it. --Nemo 08:28, 26 August 2014 (UTC)

Throwing things

Throwing things that fly through my head:

• Varnish
• Memcached

If you are also looking for stuff that is used on projects:

• IIPImage, run from ToolLabs, is linked by default for all uses from Wikimedia Commons.

Hope that helps, Jean-Fred (talk) 13:19, 20 March 2014 (UTC)

Given the lack of oppose, I added a new section for proejcts embedded/linked/used/etc. on projects, started with IIP. (I suppose there are some JS libraries that have copied over to many projects) Jean-Fred (talk) 10:09, 16 April 2014 (UTC)

MySQL/MariaDB? Apache? Should we add those? Sharihareswara (WMF) (talk) 15:31, 3 June 2014 (UTC)

INVALID bugs

To make this more concrete, we could perhaps look at which software causes problems to our users which we could not address. One possible source to mine: INVALID bugs mentioning "upstream". --Nemo 08:44, 26 August 2014 (UTC)

Non-WMF but still MediaWiki-used stuff

I ended up here from T96013 which asks the question of "top technical partners" for Wikimedia. Is it assumed that these partners, who benefit the WMF, are the same that benefit non-WMF use of MediaWiki? These are overlapping in many ways, but I have a feeling the focus is different here.

Where would things like Semantic MediaWiki or maybe even BlueSpice go? They're built on top of MediaWiki but are not used (and sometimes unacknowledged) by WMF. There's also this long tail of MediaWiki usage that's not being addressed. Yes, WMF properties are ginormous in comparison to the smaller wikis third-party users administer. There are many partners who are small and in aggregate could be a large contributing force (for lack of a better word) to MediaWiki itself. I understand it is easier to manage big, well known (comparatively) projects and parters, but I encourage us to not forget about the little guys.

Here's an incredibly selfish example. I work for a large non-profit healthcare system. I am the wiki support team. Upgrades, features, support, training, etc. VisualEditor support for IE 9 would be amazing. It's not a priority for WMF, because for their uses (undeniably) IE 9 is an infinitesimal percentage of visitors. For the many small wikis is the same true?

I apologize if this is off topic and being addressed elsewhere. Please do enlighten me if there's other efforts underway. I try to keep up on things, but often fail. :)

I also suggest we add Composer to the list somewhere. Maybe in a new section called "Non-WMF but still MediaWiki-used stuff"?

I've added composer. Do you have anything else in mind? --Nemo 21:54, 18 April 2015 (UTC)

Travis CI

Should Travis be included? It seems some people use it even for Gerrit-first repositories. I'm not sure whether there is a repository and issue tracker for everything (from their website it seems open core, but there is mixed information on this). --Nemo 11:58, 9 June 2018 (UTC)