Quoting MZMcBride: "...the two issues (a rush to deploy
features versus resource allocation for unwanted features), while
sometimes intertwined, can certainly also be discrete." I agree with you
in this point, and the Technical Committee is intended in part to
improve both situations.
Quoting David: "Unfortunately - and we quite definitely saw this in the
VE introduction - it leaves a lot of them in the position of customer
service ablative firewall, the designated targets of people's
frustration." Yes, and this is unfortunate. I sometimes feel that the
Community Advocacy and Engineering Community Liaison groups get
blame for decisions that were made by other people, and these
liaisons are placed in the difficult position of trying to please
everyone. I have sympathy for the people in those roles and I feel that
they often do good work for the WMF and the community.
Quim, it seems to me that the methods used by Features have repeatedly
produced troubled results over the years, so it's time for a different
approach. Grantmaking has a community-intensive approach
to making major decisions and I think the same approach should be
taken in Features. I am optimistic that embedding the community deeply in
leading Features would be a long-term change for the better. I believe that
the Tech Ambassadors aren't empowered to make high-level community
recommendations about Features as the Technical Committee is intended
to do, although Tech Ambassadors may want to volunteer to serve on the
Technical Committee and/or be integrated into its work. I would like to
invite
you and the Tech Ambassadors to participate in the discussion about the
Technical Committee on the Board Noticeboard [1].
Pine
[1] https://meta.wikimedia.org/wiki/Board_noticeboard
Thanks to the great collaboration that happened during the Wikimania
2014 hackathon, you can now type:
$ vagrant enable-role wikidata
$ vagrant provision
and get a locally installed WikiData rep wiki at
http://wikidata.wiki.local.wmftest.net:8080/ with the main wiki at
http://127.0.0.1:8080/.
This rides on the back of a change that converts MediaWiki-Vagrant to
use a bootstrapping system for all wikis that is a slimmed down
version of the multiversion code from the WMF's production hetdeploy
[0]. This is the latest version of the multiwiki support that was
started during the Zürich hackathon.
This may or may not include some bugs. If you update and the initial
visit you make to your local wiki say something like "No
MWMultiVersion instance initialized! MWScript.php wrapper not used?"
this means that the new multiwiki setup is a little wonky in your VM.
When this happened to Aude, running `vagrant reload` fixed it. I went
for the nuclear option of `vagrant destroy -f; vagrant up` myself.
Remember VMs are cattle and not pets. [1]
I'd like to give a big thanks to Ori, MaxSem, Dan Duvall, Gilles
Dubuc, Gergő Tisza and the tons of other folks who have helped this
week and in the last month or two to make MediaWiki-Vagrant as useful
as it is today. I'd also like to thank all of the users who have
installed it and then gone on to report bugs, make patches and build
new features for MediaWiki and its extensions.
If you've got a bit of time to wait for your vm to build try this out:
$ vagrant destroy -f
$ vagrant reset-roles
$ vagrant enable-role centralauth cirrussearch commons echo fss \
globalcssjs math multimedia multimediaviewer scribunto \
thumb_on_404 uploadwizard wikidata
$ vagrant up
Then go to http://foo.wiki.local.wmftest.net:8080/ to see a list of
all the wikis that are installed and wander around through them to
check out the features.
[0]: https://wikitech.wikimedia.org/wiki/Hetdeploy
[1]: http://www.networkworld.com/article/2165267/cloud-computing/why-servers-sho…
Bryan
--
Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org>
[[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA
irc: bd808 v:415.839.6885 x6855
This is fantastic progress, and really promising data. Huge kudos, guys :)
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
On Fri, Aug 8, 2014 at 4:15 PM, Giuseppe Lavagetto <glavagetto(a)wikimedia.org
> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 08/08/14 14:36, Ori Livneh wrote:
> > On Tue, Aug 5, 2014 at 6:53 PM, Ori Livneh <ori(a)wikimedia.org
> > <mailto:ori@wikimedia.org>> wrote:
> >
> > On either Thursday or Friday of this week, Giuseppe Lavagetto (of
> > the Wikimedia TechOps team) and I are planning to migrate
> > <https://test.wikipedia.org/> (testwiki) to HHVM. [snipped]
> >
> >
> > {{done}} :)
> >
> >
>
> Some poor man's benchmarks, just to show ourselves if we're on the
> good path...
>
>
> I ran some tests on both testwiki and one "traditional" appserver
> running Zend PHP. As the appserver was currently out of rotation, it
> was getting exactly zero traffic; testwiki receives negligible traffic
> and that won't affect our results.
>
> We decided to run the simplest test of all, by requesting a lot (a
> LOT) of times the same page, testwiki's main page, bypassing all the
> outer cache layers to test exactly the performance and throughput of
> the appservers. When reading the results, keep into account that the
> hhvm appserver is heavily underoptimized at the moment and I'm
> confident in the coming weeks we'll be able to squeeze quite some
> performance out of it. Also keep in mind we still have to road-test
> hhvm for bugs and stability, so we are not going to roll out
> everywhere over the weekend :)
>
> So, here are the results:
>
> 1) Speed test: measure the time taken to request the page 1000 times
> over just 10 concurrent connections:
>
> HHVM Zend diff
> Mean time (ms): 233 441 -47%
> 99th percentile (ms): 370 869 -57%
> Request/s: 43 22.6 +90%
>
> HHVM is clearly faster, a lot faster (its 99th percentile is below the
> mean response time for zend...), Note that the load generated in this
> situation is comparable to the everyday load of one appserver.
>
>
> 2) Load test: measure how much thoughput we obtain when hogging the
> appserver with 50 concurrent requests for a grand total of 10000
> requests. What I wanted to test in this case was the performance
> degradation and the systems resource consumption
>
> HHVM Zend diff
> Mean time (ms): 355 906 -61%
> 99th percentile (ms): 791 1453 -45%
> Request/s: 141 55.1 +156%
> Network (Mbytes/s) 17 7 +142%
> RAM used (GBs): 5(1) 11(4)
> CPU usage (%): 90(75) 100(90)
>
> for RAM show the total ram occupied and the one actively occupied by
> mediawiki, respectively; for CPU the total and user-dedicated cpu
> usage. Here numbers show that the Zend appserver is clearly over
> capacity, while the HHVM one is only nearing its limits.
>
> This benchmark is very crude and I repeated measurements just a few
> times (but the results were pretty stable across runs). But I think we
> can safely conclude that HHVM delivers the kind of performance boost
> we expected - the boost in request/s in the load test is probably the
> most important thing to highlight here. Still, I won't take these
> numbers as projections on real-world usage of mediawiki, but we're
> prettty close to an accurate test.
>
> Cheers,
>
> Giuseppe
>
> - --
> Giuseppe Lavagetto
> Wikimedia Foundation - TechOps Team
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iEYEARECAAYFAlPk6XYACgkQTwZ0G8La7IAZNgCgizdLmtYzlVoMSwLZiCcY8lxL
> rbAAn0/LOkUx7JEkxs3EQQWRV5x1CO6D
> =nQBt
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Engineering mailing list
> Engineering(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/engineering
>
(apologies for cross-posting)
On either Thursday or Friday of this week, Giuseppe Lavagetto (of the
Wikimedia TechOps team) and I are planning to migrate <
https://test.wikipedia.org/> (testwiki) to HHVM. The way testwiki is
configured makes it a natural next step on the path leading from the Beta
Cluster to production. Specifically, testwiki is served by the same
load-balancer, reverse-proxy, and database servers as the rest of
production, but it is powered by a single application server that is
segregated from the pool of servers that handle requests for all other
Wikimedia wikis. This means that if we run into stability issues with HHVM,
they will be confined to just testwiki, and will not spill over to other
sites.
To migrate testwiki to HHVM, Giuseppe will need to take the server that
powers testwiki off-line for several hours for re-imaging. Ordinarily, we
design our infrastructure for redundancy and graceful failover, so we can
take machines offline without impacting users. But the corollary to
testwiki being a special case is that it is not configured in this way. As
I explained above, this is just as well, because it means we can perform
this work without disturbing the rest of the cluster.
Giuseppe and I will provide additional notices via IRC and e-mail prior to
beginning this work. We know that testwiki is used by a diverse user-base
to test various MediaWiki software components and will do our best to
minimize disruption to such users. Feel free to get in touch via e-mail or
IRC (my nickname is 'ori') if you have concerns about the deployment.
Thanks for your patience and understanding! :)
Ori
With due notes that I just yesterday updated my nick and my e-mail, and I'm the one who started this thread;
On Wed, 6 Aug 2014, at 06:58, Quim Gil wrote:
> > - encourage feedback by absolutely /anyone/ about the next features they'd
> > like,
> >
>
> Betas and Bugzilla today. Phabricator should make it easier to provide
> feedback in a wider range of topics, not only "bugs".
99% of users of Wikimedia projects don't /know/ about these tools. That's the problem, and your response is not reflecting it.
>
>
> > - run programming and documentation activities requested (or started) by
> > community [there would be a lot of small projects, unlike the big ones the
> > current Teams are working on],
> >
>
> I for one would welcome more initiatives and requests from the community.
> The PyWikiBot is a good example of a team that asks us to help organizing
> and promoting their special activities. More proposals are welcome.
Listening to me (or other mailing list members) here or in your personal e-mail is not the way to go, as mentioned in my earlier line.
> > - encourage localising documentation for, and centralising the location
> > of, all community-developed programming work,
> >
>
> Nemo has been a very active advocate, and I want to believe that WMF teams
> have been increasingly relying on centralized and translatable
> documentation in their releases, asking explicitly for translation help.
I had trouble talking with Nemo. He doesn't go in lengthy discussions about development and explaining things on IRC. Is he more willing to follow-up and give examples over e-mail? Probably; I have not tried.
On the plus side, I've had infinitely nice experience with him regarding translations of documentation.
> > - raise awareness of community development efforts across all Wikimedia
> > projects,
> >
>
> This is an explicit goal for Tech Ambassadors and Community Liaisons.
Related message:
http://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073696.html
>
>
> > - actively encourage members of community become MediaWiki and Gadgets
> > hackers in the Free Software philosophy?
> >
>
> Ah, you are touching a point of my personal ToDo list that I know we are
> not addressing as well as we could.
That is correct, and is the problem.
> Still, we are trying to focus this line
> of activity in conjunction with our participation in Google Summer of Code,
> FOSS Outreach Program for Women, and recently also Google Code-in and
> Facebook Open Academy.
Those, and IEG/PEG grants, scratch only a very small part of the userbase, and only their bigger projects. The problem is with engaging a vast majority of userbase in scripting the software to meet their personal needs.
See, for instance, with Firefox, customizing is exceptionally easy using existing add-ons or writing your own using the Jetpack. These are well-documented technologies and they're also, unlike what happens at Wikimedia projects, well advertised to end users.
"Would you like to see MediaWiki as openly customizable as Firefox?"
> This would be, in my view, a relatively small, collaboration-type team
> > (with just half a handful of people for timezone coverage for IRC support).
> >
>
> To me this is not a task of one team or two, but a set of practices better
> embodies in our development and deployment processes, and also a set of
> activities that a larger community should embrace.
>
> In fact, this is what my Wikimania session is about! Shameless plug:
>
> https://wikimania2014.wikimedia.org/wiki/Submissions/The_Wikimedia_open_sou…
Wikimania people are a tiny part of the userbase. _How_ would you do what you're talking about there? This is not mentioned in the abstract, even though the problem raised is similar.
>
> (It was scheduled at the "Technology, Interface & Infrastructure" track but
> believe me, it's more about
> WikiCulture & Community.)
>
> I'm curious about the subject of you message, especially the "let's elect
> people" part. What do you mean?
Community volunteers could be featured for their technical work, and get rigorous feedback from community. If some of them start doing it contrary to community expectations, there should be means to clearly display that (and kick them out if they start doing rubbish and fail to hear the said feedback). -- This is very unclear and unspecific. I would expect others to come up with a specific mechanism for such cases.
Svetlana.
Replying with a subject line. :) Good luck Thomas.
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
On Thu, Jul 24, 2014 at 4:24 PM, Thomas Mulhall <thomasmulhall410(a)yahoo.com>
wrote:
> Hi should we upgrade jquery ui to version 1.10.4. even though we recently
> upgraded to version 1.9.2 we could upgrade to 1.10.4 in Mediawiki 1.25. The
> main difference is it removes internet explorer 6 support which as long as
> internet explorer 6 users can edit and view the page it wont matter to
> them. here is the changelog jqueryui.com/changelog/1.10.0/
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Dear colleagues and fellow enthusiast of the semantic web,
we are pleased to announce that the SEMANTiCS conference on Sep 4-5,
2014 in Leipzig, will become a major industry conference on semantic web
and linked data applications in Europe.
With partners such as PoolParty, STI2, Eccenca, IntraFind, LOD2 Project,
MarkLogic, Ontos and Wolters Kluwer as well as more than 50% of our
currently registered attendees being from the industry sector, SEMANTiCS
has lifted the primarily academic topic of semantic web to the next
level of business application.
From our keynote speakers Sofia Angeletou (BBC), Thomas Kelly
(Cognizant), Phil Archer (W3C) and Orri Erling (OpenLink) to 40+
speakers on 5 parallel tracks and special events like the vocabulary
carnival, H2020 networking event and conference dinner, SEMANTiCS offers
a wide variety of industry insights and networking chances. You can see
our programm here: http://www.semantics.cc/programme/
Hence, this year's SEMANTiCS conference is your chance to get in touch
with potential business clients and industry partners to push your own
projects and developments in the semantic web sector.
You can still submit to the Vocabulary Carnival:
http://www.semantics.cc/vocarnival/ as well as the H2020 networking
session. Furthermore, we will collect and print your H2020 organisation
profile description in the program guide, so you can be approached at
the conference for potential projects.
Being a fellow enthusiast in this future-defining field, we'd like to
offer you a special discount of 20% on your ticket to the conference.
Simply go to www.semantics.cc/registration/discount and claim your
discount with the following promo code: “semantic-web-fellow”
This offer is valid until 15th of August.
For further information on the programme and our keynote speaker, please
visit www.semantics.cc
Feel free to forward this email to any interested fellow.
See you in Leipzig,
Sebastian Hellmann
on behalf of the all conference committee members
--
Sebastian Hellmann
AKSW/NLP2RDF research group
Insitute for Applied Informatics (InfAI) and DBpedia Association
Events:
* *Sept. 1-5, 2014* Conference Week in Leipzig, including
** *Sept 2nd*, MLODE 2014 <http://mlode2014.nlp2rdf.org/>
** *Sept 3rd*, 2nd DBpedia Community Meeting
<http://wiki.dbpedia.org/meetings/Leipzig2014>
** *Sept 4th-5th*, SEMANTiCS (formerly i-SEMANTICS) <http://semantics.cc/>
Venha para a Alemanha como PhD: http://bis.informatik.uni-leipzig.de/csf
Projects: http://dbpedia.org, http://nlp2rdf.org,
http://linguistics.okfn.org, https://www.w3.org/community/ld4lt
<http://www.w3.org/community/ld4lt>
Homepage: http://aksw.org/SebastianHellmann
Research Group: http://aksw.org
Thesis:
http://tinyurl.com/sh-thesis-summaryhttp://tinyurl.com/sh-thesis
Yep, if you look at the Hackathon schedule you should see that it has been
scheduled for Thursday afternoon at 2pm. Hope you can make it!
On Wed, Aug 6, 2014 at 3:03 AM, Emeric Vallespi <emeric.vallespi(a)gmail.com>
wrote:
> Hello,
>
> Does anyone have planned a meeting during Wikimania about next Hackathon's
> organization ?
> I believe it would be useful to know who of us still want to organize,
> after informations which was forwarded by former organizers, and how we
> could collaborate to choose the next (co-)organizer.
>
> I will be around the Wikimania Hackathon this afternoon and tomorrow, let
> me know if you're interested with this discussion.
> (Jean-Frederic & Sylvain are also available)
>
> --
> Emeric Vallespi
> Vice-treasurer
> Wikimedia France
>
> emeric.vallespi(a)wikimedia.fr
> Twitter: @evallespi
>
>
>
> On 16 juil. 2014, at 21:00, Emeric Vallespi <emeric.vallespi(a)gmail.com>
> wrote:
>
> > Hi,
> >
> > WMFr is still thinking about organizing Wikimedia Hackathon in 2015. We
> are currently identifying the technical, financial and especially human
> resources needed to make it a success.
> >
> > Frans, could you provide me/us your documentation or the link (Meta ?) ?
> It would be very useful.
> >
> > Wikimedia France really wants to organize an international event in 2015.
> >
> > Anyway, we believe that if another chapter wants to organize Hackathon
> it could be a waste of time for one of us to position our proposals against
> until the result.
> >
> > So if a sister entity positions herself clearly and seriously to
> organize Wikimedia Hackathon we can discuss it.
> >
> > Best regards,
> > --
> > Emeric Vallespi
> > Vice-Treasurer
> > Wikimedia France
> >
> > emeric.vallespi(a)wikimedia.fr
> > Twitter: @evallespi | Mob. +33 (0)6 61151312
> >
> > On 14 juil. 2014, at 20:38, Frans Grijzenhout <frans(a)wikimedia.nl>
> wrote:
> >
> >> Hi Balázs, WMNL hosted the international hackaton in 2013.
> Documentation is
> >> archived and thus still available and we are more than willing to help
> you
> >> in preparing the international hackaton in 2015.
> >> Regards, Frans
> >>
> >>
> >>
> >> *Frans Grijzenhout*, voorzitter / chair
> >> frans(a)wikimedia.nl
> >> +31 6 5333 9499
> >> http://www.wikimedia.nl/
> >>
> >> *Vereniging Wikimedia Nederland*
> >> *Postadres*: *Bezoekadres:*
> >> Postbus 167 Mariaplaats 3
> >> 3500 AD Utrecht 3511 LH Utrecht
> >>
> >> ABNAMRO NL33 ABNA 0497164833 - Kamer van Koophandel 17189036
> >>
> >>
> >>
> >>
> >> 2014-07-14 16:56 GMT+02:00 Balázs Viczián <balazs.viczian(a)wikimedia.hu
> >:
> >>
> >>> Hi,
> >>>
> >>> WMHU would be interested in *hosting *a Hackathon in Hungary
> (anywhere) but
> >>> we would need a couple of international volunteers to help filling the
> core
> >>> of event (finding topics and speakers or building up the content in
> >>> general). In exchange, the rest (from side events to the smallest
> details)
> >>> can be left with us :)
> >>>
> >>> Balazs
> >>>
> >>>
> >>> 2014-07-14 14:53 GMT+02:00 Frans Grijzenhout <frans(a)wikimedia.nl>:
> >>>
> >>>> Hi Romaine, this is to remind you that the CoSyne project was a
> research
> >>>> project, sponsored by the EU and conducted by different partners. The
> >>>> research has been concluded and the results have been reported early
> >>>> 2013..The technical infrastructure has sinds then been dismantled, so
> it
> >>>> will not be that easy to restart CoSyne. Regards, Frans
> >>>>
> >>>>
> >>>> *Frans Grijzenhout*, voorzitter / chair
> >>>> frans(a)wikimedia.nl
> >>>> +31 6 5333 9499
> >>>> http://www.wikimedia.nl/
> >>>>
> >>>> *Vereniging Wikimedia Nederland*
> >>>> *Postadres*: *Bezoekadres:*
> >>>> Postbus 167 Mariaplaats 3
> >>>> 3500 AD Utrecht 3511 LH Utrecht
> >>>>
> >>>> ABNAMRO NL33 ABNA 0497164833 - Kamer van Koophandel 17189036
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> 2014-07-09 23:44 GMT+02:00 Romaine Wiki <romaine.wiki(a)gmail.com>:
> >>>>
> >>>>> I doubt if these tools are similar. But I do think they can benefit
> >>> from
> >>>>> each other.
> >>>>>
> >>>>> Romaine
> >>>>>
> >>>>>
> >>>>> 2014-07-09 16:03 GMT+02:00 Antoine Musso <hashar+wmf(a)free.fr>:
> >>>>>
> >>>>>> Le 09/07/2014 14:33, Romaine Wiki a écrit :
> >>>>>>> As a subject of one/more hackathons I would like to recommend
> >>> CoSyne
> >>>>> [1].
> >>>>>>> CoSyne is translation and multilingual synchronisation tool. The
> >>>>> project
> >>>>>>> was set up by Wikimedia Netherlands together with several
> >>>> universities
> >>>>>> and
> >>>>>>> other partners, including the EU. The tool makes it possible to
> >>>>> translate
> >>>>>>> much more easier from one Wikipedia (etc) to another with much
> >>> better
> >>>>>>> quality translations than existing translating tools. It does not
> >>>>> matter
> >>>>>> if
> >>>>>>> an article is already written, it is possible with this tool to
> >>>> expand
> >>>>>>> existing articles and to update articles with a new section when on
> >>>> one
> >>>>>>> Wikipedia this was added. It makes it possible to exchange
> >>>> information
> >>>>> in
> >>>>>>> more languages and helps users to keep the articles up-to-date.
> >>>>>>>
> >>>>>>> I have tested the Bèta version of this tool and these tests were
> >>> very
> >>>>>>> successful.
> >>>>>>>
> >>>>>>> [1] https://nl.wikimedia.org/wiki/CoSyne
> >>>>>>>
> >>>>>>> Romaine
> >>>>>>
> >>>>>> Hello,
> >>>>>>
> >>>>>> Seems it is very similiar to the content translation Wikimedia i18n
> >>>> team
> >>>>>> is working on:
> >>>>>>
> >>>>>> http://www.mediawiki.org/wiki/Content_translation
> >>>>>>
> >>>>>> Demo video:
> >>>
> http://www.mediawiki.org/wiki/File:CX_Section_Alignment_Preview_and_Basic_E…
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Antoine "hashar" Musso
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Wikimedia-l mailing list, guidelines at:
> >>>>>> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> >>>>>> Wikimedia-l(a)lists.wikimedia.org
> >>>>>> Unsubscribe:
> >>> https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> >>>>>> <mailto:wikimedia-l-request@lists.wikimedia.org
> ?subject=unsubscribe>
> >>>>> _______________________________________________
> >>>>> Wikimedia-l mailing list, guidelines at:
> >>>>> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> >>>>> Wikimedia-l(a)lists.wikimedia.org
> >>>>> Unsubscribe:
> https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> >>>>> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> >>>> _______________________________________________
> >>>> Wikimedia-l mailing list, guidelines at:
> >>>> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> >>>> Wikimedia-l(a)lists.wikimedia.org
> >>>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
> ,
> >>>> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> >>> _______________________________________________
> >>> Wikimedia-l mailing list, guidelines at:
> >>> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> >>> Wikimedia-l(a)lists.wikimedia.org
> >>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> >>> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> >> _______________________________________________
> >> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> >> Wikimedia-l(a)lists.wikimedia.org
> >> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
Hi all.
WMF Engineering is currently composed of individual teams as documented at https://www.mediawiki.org/wiki/Wikimedia_Engineering . These teams look after the software that faces us everyday, and often work together.
Could we please have some more people (potentially a dedicated ‘community’ team) who could do these things:
- encourage feedback by absolutely /anyone/ about the next features they'd like,
- run programming and documentation activities requested (or started) by community [there would be a lot of small projects, unlike the big ones the current Teams are working on],
- encourage localising documentation for, and centralising the location of, all community-developed programming work,
- raise awareness of community development efforts across all Wikimedia projects,
- actively encourage members of community become MediaWiki and Gadgets hackers in the Free Software philosophy?
This would be, in my view, a relatively small, collaboration-type team (with just half a handful of people for timezone coverage for IRC support).
Open to brainstorming and suggestions. I would compile thoughts into a wiki page afterwards to continue thinking on the idea.
Regards
Gryllida.