[Wikitech-l] Fwd: [Wikimedia-l] Project Grants program will fund 20 community-led projects

[Pine W]

Forwarding in case people are interested in seeing what was funded.

Pine
( https://meta.wikimedia.org/wiki/User:Pine )


-- Forwarded message -
From: Chris "Jethro" Schilling 
Date: Fri, Mar 1, 2019 at 9:06 PM
Subject: [Wikimedia-l] Project Grants program will fund 20 community-led
projects
To: Wikimedia Mailing List 


Hi folks,

In the latest round of Project Grants, the committee has recommended 20
projects for a total of approximately $678,666 USD in funding.  We received
42 proposals for review, the largest round of proposals we’ve received in a
single round. Please join me in congratulating the applicants! I’d also
like to express my thanks to all applicants this round for their hard work
and engagement with their proposals, and to the Project Grants Committee
for their careful diligence in reviewing and providing crucial feedback
during this round. Without further ado, here’s what we’re funding:[1]

==Software: five projects funded==* Commons Android app v3: This third
version of the Commons mobile uploader app aims to increase app stability,
improve a recommendations feature for nearby places, maintain a limited
connectivity mode, and provide better outreach to underrepresented
communities. [2]

* Scribe: Scribe is an editing tool to support underserved Wikipedia
editors, helping them to plan the structure of their new articles and to
find references in their language.[3]

* Culture Gap Monthly Monitoring: The Wikipedia Cultural Diversity
Observatory (WCDO) proposes a set of solutions to regularly assist
communities and individual editors to increase the cultural diversity in
their language editions’ content.[4].

* GlobalFactSyncRE: GlobalFactSyncRE will extract all infobox facts and
their references to produce a tool for Wikipedia editors that detects and
displays differences across infobox facts in an intelligent way to help
sync infoboxes between languages and/or Wikidata. The extracted references
will also be used to enhance Wikidata.[5]

* Wikidata & ETL: This project aims at improving management and increasing
automation of processes loading data into Wikidata, and proposes a tool as
a platform for creation of repeatable processes for bulk loading data into
Wikidata and other Wikibase instances from various data sources.[6]

==Online organizing: four projects funded==* Wiki Loves Monuments
international team/2019 coordination: The international coordination team
for Wiki Loves Monuments (WLM) [7] proposes to strengthen the foundation
for healthy and sustainable WLM competitions across the world. In this
grant, the team will focus considerable effort on increasing the
sustainability of these events by addressing known issues around developing
best practices, resourcing local teams to run successful events, and
adapting to mobile engagement.[8]

* CEE Spring 2019: This annual international article writing contest
generates
content from every country and region in Central and Eastern Europe on 30+
Wikipedias.  CEE Spring’s remarkable community spirit plays a central role
in fostering a thriving, collaborative volunteer base in the region. The
grant will continue incentivizing content creation focused on similar
themes from last year, including closing the gender gap, and expanding
minority language Wikipedias, and showcasing the cultural heritage of
Central and Eastern Europe. [9]

* WM HU/Editor retention program: This grant will fund the editor retention
program in the Hungarian Wikipedia. The project helps the Hungarian
Wikipedia community in decreasing the negative experiences and
strengthening the positive experiences of the contributors; improving the
community atmosphere and strengthening the community cohesion, the
Wikipedia identity, the sense of mission and pride in Wikipedia.[10]

* VisibleWikiWomen2019: Whose Knowledge?, in partnership with Wikimedians
and women’s and feminist organizations around the world, is organizing a
campaign to add more diverse and quality images of women to Commons and
Wikipedia throughout March 2019 to celebrate International Women’s Month.
This year, the organization plans to take what they have learned from 2018
#VisibleWikiWomen and grow the campaign, creating more materials and
connections that will be useful for this year’s campaign and many more
years to come.[11]

==Offline outreach: ten projects funded==* Smithsonian
Wikimedian-in-Residence for Gender Representation: This project will
establish a Wikimedian-in-Residence for the Smithsonian Women's History
Initiative, and increase the representation of women on Wikimedia projects,
and seek ongoing support for a permanent Wikimedian-in-Residence at the
institution.[12]

* Action Plan for Wikipedia + Libraries Training in Mexico: OCLC will
investigate the viability of and approach to a Wikipedia+Libraries training
program for library staff in Mexico, to leverage the libraries in support
of the Wikimedia Foundation’s New Readers initiative. This project will
identify a Mexico-based 

[Wikitech-l] TechCom Radar 2019-02-27

[Kate Chapman]

Hi All,

Here are the minutes from this week's TechCom meeting:

* On Last Call ending March 6 1pm PST(21:00 UTC, 22:00 CET) RfC:
Standards for external services in the Wikimedia infrastructure


* Approved: Update to Gerrit privilege policy
 (also approved by CTO)

* IRC meeting next week March 6 2pm PST(22:00 UTC, 23:00 CET) in
#wikimedia-office RFC: Abstract schemas and schema changes


* Scheduling IRC discussion soon RFC: Add a frontend build step to
skins/extensions to our deploy process


* Scheduling IRC discussion soon RFC: Let's stop using QUnit as a
mechanism for integration tests


* RFC: Store WikibaseQualityConstraint check data in persistent
storage  reviewed and needs
further discussion.

* There was no IRC meeting this week

You can also find our meeting minutes at


See also the TechCom RFC board
.

If you prefer you can subscribe to our newsletter here


Thanks,
Kate

--
Kate Chapman
Senior Program Manager, Core Platform
Wikimedia Foundation
kchap...@wikimedia.org

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Code sniff for verbose conditionals

[Thiemo Kreuz]

Sorry it took me so long to respond here.

In https://gerrit.wikimedia.org/r/486813 Gergő wrote:

> […] it adds some fairly complicated code for detecting a pattern that's 
> mostly harmless and can be dealt with during normal code review, so the value 
> is less than the maintenance cost.

Thanks! I think this sums it up really well.

> we should aim for a threshold which would only reject code that is clearly 
> wrong […]

See, that's the problem: I don't think a single of the examples I have
seen so far is "clearly wrong". I don't think there is anything
"wrong" with explicitly stating all possible return values. Yea, one
*might* consider some of the examples a little tooo expressive. Some
of them *can* be shortened. But when this is the case and when not is
more an opinion than anything, and needs to be talked about in a code
review.

> […] doesn't mean that we should avoid dealing with it without even trying.

I don't think this question was answered yet: What are we even trying
to solve here? How big of an issue is this? How often do we come
across such code during our code reviews and feel "I wish a sniff
would have found this before I did"? I do a ton of code reviews. Yes,
there is code like this. But from my personal experience this is so
rare and so much a matter of personal preference and opinion that it's
not worth dealing with the maintenance costs a fully-automated sniff
comes with.

> Could you provide specific examples where my proposed approach produces an 
> undesirable outcome? That is, an example of code you believe should be 
> acceptable but would be marked as fixable?

I'm sorry, but I believe it should not work this way around. I would
like to point to the examples in the test file. Sure, some of them
*can* be rewritten in a shorter way. But none of them *must* be
rewritten.

CodeSniffer rules are not to make suggestions (actually they are, but
that's not how we use them). The moment we make a sniff report certain
patterns, somebody will come and try to "fix" it, no matter how much
sense it makes. Not long ago a sniff complained about uncommented
@param tags, and people started adding cruft like `@param User $user
The user object`. I would like to avoid running into the same
situation again when we have much more pressing problems, e.g. bad
test coverage, or God objects with hundreds of static methods and
several thousand lines. *These* should make a sniff fail that forbids
making code too complex.

Kind regards
Thiemo

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l