Hi all,
There are online small business accounting software packages. Do any
thematic orgs have experience with them? Any recommendations? I am thinking
about proposing Quickbooks Online for the Cascadia user group, but as this
Forbes article says, there are competitors:
http://www.forbes.com/sites/quickerbettertech/2014/01/06/why-your-company-m…
Thanks,
Pine
Hi folks,
At the Zurich Hackathon, I met with a couple of folks from WM-CH who
were interested in talking about ways that chapters can get involved
in engineering/product development, similar to WM-DE's work on
Wikidata.
My recommendation to them was to consider working on GLAM-related
tooling. This includes helping improve some of the reporting tools
currently running in Labs (primarily developed by the illustrious and
wonderful Magnus Manske in his spare time), but also meeting other
requirements identified by the GLAM community [1] and potentially
helping with the development of more complex MediaWiki-integrated
tools like the GLAMWiki-Toolset.
There's work that only WMF is well positioned to do (like feeding all
media view data into Hadoop and providing generalized reports and
APIs), but a lot of work in the aforementioned categories could be
done by any chapter and could easily be scaled up from 1 to 2 to 3
FTEs and beyond as warranted. That's because a lot of the tools are
separate from MediaWiki, so code review and integration requirements
are lower, and it's easier for technically proficient folks to help.
In short, I think this could provide a nice on-ramp for a chapter or
chapters to support the work of volunteers in the cultural sector with
appropriate technology. This availability of appropriate technology is
clearly increasingly a distinguishing factor for Wikimedia relative to
more commercial offerings in its appeal to the cultural sector.
At the same time, WMF itself doesn't currently prioritize work with
the cultural sector very highly, which I think is appropriate given
all the other problems we have to solve. So if this kind of work has
to compete for attention with much more basic improvements to say the
uploading pipeline or the editing tools, it's going to lose. Therefore
I think having a "cultural tooling" team or teams in the larger
movement would be appropriate.
I've not heard back from WM-CH yet on this, but I also don't think
it's an exclusive suggestion, so wanted to put the idea in people's
heads in case other organizations in the movement want to help with
it. I do want WMF to solve the larger infrastructure problems, but the
more specialized tooling is likely _not_ going to be high on our
agenda anytime soon.
Thanks,
Erik
[1] https://upload.wikimedia.org/wikipedia/commons/a/a2/Report_on_requirements_…
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
On Fri, Jul 11, 2014 at 10:37 AM, Andy Mabbett
<andy(a)pigsonthewing.org.uk> wrote:
> It's interesting to read that claim in the content of my "aversion" to
> the unexpected removal of the very useful 'nearby' feature from the
> Android app [1].
(...)
> [1] Promoted by the WMF at the time of its launch:
> http://blog.wikimedia.org/2013/05/29/wikipedia-nearby-beta/ and widely
> reported in the press.
Apologies for the thread-split, but this is OT from the original thread.
This blog post actually referred to the Mobile Web, where the feature
continues to be available (without a map view):
http://en.m.wikipedia.org/wiki/Special:Nearby
The new Android app isn't simply an upgrade of the last version, it's
a complete re-write in native code -- one which by all accounts has
been extremely well received. In determining the feature set, the team
looked at core functionality they really wanted to deliver in the
first release, and iterated on that based on user feedback during the
beta.
We are in the lucky position to now have a team of three full-time
developers working on the app to make it continually better. You can
see the most recent code changes here:
https://gerrit.wikimedia.org/r/#/q/apps/android,n,z
And a more understandable view of the current sprint in Trello:
https://trello.com/b/5DhKhjmW/mobile-app-sprint-35-article-usability-enhanc…
So you can expect a pretty fast pace of change.
The team prioritized features that were highly requested and popular
among users. The "nearby" feature in the old app also relied on third
party infrastructure, which makes us a bit uncomfortable from a user
privacy and principles perspective. Our plan is to build out our own
OpenStreetMap infrastructure later this year which will help in
further developing such geo-functionality.
CCing Dan (PM for Apps) in case he wants to weigh in on the roadmap.
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Dear Wikimedians,
Wikimania is the global, annual conference of the Wikimedia movement,
organised by the Wikimedia community. Organizing team and location are
chosen by a jury in a public bidding process.
Due to the growing requirements and complexity for this growing
conference the Wikimania Committee decided to revise the bidding
timeline to give more time to prepare the conference.
Here it is:
* https://meta.wikimedia.org/wiki/Wikimania_2016_bid_selection_timeline
== Jury ==
The Wikimania Committee is pleased to announce the jury for Wikimania 2016:
Richard Symonds
Stuart Prior
Claudia Garad
Esteban Zarate
Daniel Bryant
Finne Boonen
Ellie Young
== Accepting Bids ==
We invite anyone in our community to submit a proposal for Wikimania
2016 on Meta Wiki:
* https://meta.wikimedia.org/wiki/Wikimania_2016_bids
Please consult the timeline and Judging Criteria that are posted at:
* https://meta.wikimedia.org/wiki/Wikimania_2016_bids
The deadline for bids is November 15, 23:59 UTC. You should setup a
bidding page and contact Ellie Young, WMF Conference Coordinator before
the deadline. She will help you prepare your bid. All bids which have
been confirmed until November 15 will be considered by the jury, others
will be dismissed.
Subsequently there will be a two week period where the community can
comment and offer feedback on the proposal.
In December your team must be available for conference calls with the
jury, after deliberations the host for Wikimania 2016 will be announced
by the end of 2014.
On behalf of the Wikimania Committee with regards,
Manuel
--
Manuel Schneider - Chief Information Officer
Wikimedia CH - Verein zur Förderung Freien Wissens
Lausanne, +41 (21) 340 66 22 - www.wikimedia.ch
tl;dr: We've been collectively whining about templates for long enough. Who
wants to help with fixing them?
In the recent discussions/debacles about technical and stylistic advances,
a recurring theme is that the use of some templates causes major headaches,
and a commonly heard complaint from the developers and designers is that
their products exhibit problems and shortcoming because of that. Anecdotal
evidence I've lately encountered includes:
* The mobile skin obfuscates talk page access because the templates
commonly found on talk pages makes them render horribly.
* The mobile skin special-cases some templates (notably issue templates and
infoboxes) because they would render horribly.
* Media-viewer has a tough time doing to correct thing with attribution and
license information because parsing template-madness is hard.
* VE development has spent a large amount of time around templates, and
it's still one of its weakest suits. Template substitution is still a
problem, as well as templates that produce wikitext that in itself doesn't
map cleanly to HTML tokens.
* Scribunto has been developed specifically because writing and maintaining
templates with more complicated logic is horrible, both from a
writers/maintainers perspective as well as from a performance perspective
All this together is sufficient to assert we have a template problem. The
main editing community has a problem with how templates are and must be
used, the readers have a problem with display issues on mobile as well as
style inconsistencies, the technical editing community has a problem with
writing and maintaining templates, and the development community has a
problem with the difficulty in correctly parsing and interpreting templates
and there contents.
It would be great if this problem were tackled; it would be even greater if
the WMF could work together with the community to identify the pain points,
and jointly take steps to tackle them. Templates are currently
extraordinarily powerful, and most if not all of this power is finding use
in the projects, possibly in ways nobody ever foresaw. As we all know from
Uncle Ben, with great power comes great responsibility, and it's about time
we all took our share of that responsibility, tough up, and fix it.
We should keep in mind that current use is paramount, and any fixing of
templates that breaks the wiki is frankly unacceptable, which probably
means we can't go from insane to sane overnight, even if we could define
sane and insane with regards to templates overnight. At the same time we
shouldn't shy away from fixes that would break some exotic use of
templates, if as part of the process of making things better, before
implementation, we can fix those templates.
I hope we can, for the coming period, accomplish the following:
* Catalog the problems with templates. Make a comprehensive list that
enumerates the problems with templates we have now, categories the problems
(right now I'm roughly thinking in style, wikitext parsing rules and
generated HTML, creation and writing issues (let's hope there is little of
this one left after Scribunto), and usability by editors).
* Note which quirks that lead to technical difficulties are used in the
wild as features rather than bugs.
* Brain storm possible (partial) solutions.
* Find candidates that have high bang-for-buck possible solutions without
impeding future improvements much.
* Refine those solutions so we know quite exactly what it will fix, what it
won't fix, and what it would possibly break.
* Define sane fallback procedures for when things break; this should mainly
come from the editing communities, but could probably use some guidance of
what is possible/easy/logical/feasible from a technical POV from the
development community.
* Fix templates.
Personally, I'm all talk and no action, so to get this of the ground we
would need a lot of help. First, we need to know if I'm on to something, or
if this is just the raving of a lunatic (please tell me if it is!). If the
idea is sound, we need to set up the infrastructure. We probably need a
Meta page set up to organise things and set up initial reconnaissance. We
need a lot of grunt work categorising issues and problems from all
perspectives: reader (this is difficult, but many groups that don't
directly represent the readers care deeply about their needs, so that's
something), template users, template maintainers, and template
infrastructure maintainers (developers). For that we need to reach out to
those different communities; this email is posted to wikimedia-l only
(because I couldn't think of a better one, but I acknowledge this doesn't
fit like a glove), but there are bound to be other interested parties out
there who want to help that this email isn't reaching.
What do you all think? Should we make this happen?
--Martijn
Dear all,
The next WMF metrics and activities meeting will take place on Thursday,
October 2, 2014 at 6 PM UTC (11 AM PDT). The IRC channel is
#wikimedia-office on irc.freenode.net and the meeting will be broadcast as
a live YouTube stream.
The current structure of the meeting is:
* Welcoming recent hires
* Update and Q&A with the Executive Director, if available
* Review of key metrics including the monthly report card, but also
specialized reports and analytic
* Review of financials
* Brief presentations on recent projects, with a focus on highest priority
initiatives
Please review
https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings for further
information about how to participate.
We’ll post the video recording publicly after the meeting.
Thank you,
Praveena
--
Praveena Maharaj
Executive Assistant to the VP of Engineering & Product Development
Wikimedia Foundation
Dear all,
We are excited to announce that the Wikimedia Foundation now has a Vice
President of Engineering. Damon Sicore will be filling this vital role.
Please join us in welcoming him to the team.
The VPE role will be crucial to further developing and maintaining the
technology that supports the very core of the Wikimedia movement, and
ensuring the development, scale, and stability of the MediaWiki
architecture.
Damon joins us as part of planned growth of our product and engineering
teams, first announced in November 2012. As we have grown, we need
dedicated focus on product and engineering as separate departments, to
ensure development of best practices like performance engineering,
continuous delivery, A/B testing, software re-architecture, UI/UX work, and
user research. Erik Moeller, who filled the role of VP for both product and
engineering since 2011, led in the creation of this new role and was
essential to the search process. From today onward, Erik will focus on his
role as VP of Product and Strategy and Deputy Director of the WMF, while
Damon will take over leadership of the Engineering team; both will report
to me as part of the c-level team.
Damon has a unique track record of managing large platform rollouts using
distributed teams like ours, while understanding the essential role of
community contributions and working in a transparent, open source
environment. These skills and experiences will be invaluable in his work
here at the Foundation. It’s unusual to find someone who understands us so
well, and so I want to thank the many people from across the organization,
especially in the engineering, product, and human resources teams, who have
been involved in making this search successful.
We are very happy to have Damon on board. His proven track record of
managing large platform rollouts using distributed teams like ours, while
understanding the essential role of community contributions and working in
a transparent, open source environment, is unique and invaluable as part of
our movement.
We’ll be sending around a copy of the press release shortly. You’ll also be
be able to meet Damon, and ask him questions, this Thursday at our monthly
Metrics Meeting
<https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings>.
Please join us there!
Please join me in welcoming Damon.
Lila
It's now over 50 days since I put in my (trivial) claim for £14 at
Wikimania. Are other volunteers having a problem getting paid what
they are due? Leaving volunteers hanging for their promised expenses
for a couple of months seems almost careless.
Hopefully speakers and trustees with significant expenses were paid
more promptly.
Thanks,
Fae
---------- Forwarded message ----------
From: Fæ <faewik(a)gmail.com>
Date: 25 September 2014 09:08
Subject: Wikimania expenses
To: UK Wikimedia mailing list <wikimediauk-l(a)lists.wikimedia.org>
Hi,
Checking my bank account I can't find any payment of my 14 quid of
travel expenses from volunteering at Wikimania. Have other volunteers
had payments yet?
Fae
(apologies for cross-posting)
I'm happy to announce that HHVM is available on all Wikimedia wikis for
intrepid beta testers. HHVM, you'll recall, is an alternative runtime for
PHP that provides substantial performance improvements over the standard
PHP interpreter. Simply put: HHVM is software that runs on Wikimedia's
servers to make your reading and editing experience faster.
You can read more about HHVM here: https://www.mediawiki.org/wiki/HHVM
* How do I enable HHVM?
You can enable HHVM by opting in to the beta feature. This short animated
gif will show you how: <http://people.wikimedia.org/~ori/hhvm_beta.gif>.
Enabling the beta feature will set a special cookie in your browser. Our
servers are configured to route requests bearing this cookie to a pool of
servers that are running HHVM.
* How do I know that it's working?
Opting-in to the beta feature does not change the user interface in any
way. If you like, you can copy the following code snippet to the global.js
subpage of your user page on MetaWiki:
https://meta.wikimedia.org/wiki/User:Ori.livneh/global.js
If you copy this script to your global.js, the personal bar will be
annotated with the name of the PHP runtime used to generate the page and
the backend response time. It looks like this:
http://people.wikimedia.org/~ori/hhvm_script.png
Edits made by users with HHVM enabled will be tagged with 'HHVM'. The tag
is there as a precaution, to help us clean up if we discover that HHVM is
mangling edits somehow. We don't expect this to happen.
* What sort of performance changes should I expect?
We expect HHVM to have a substantial impact on the time it takes to load,
preview, and save pages.
At the moment, API requests are not being handled by HHVM. Because
VisualEditor uses the API to save articles, opting in to the HHVM beta
feature will not impact the performance of VisualEditor. We hope to have
HHVM handling API requests next week.
* What sort of issues might I encounter?
Most of the bugs that we have encountered so far resulted from minute
differences in how PHP5 and HHVM handle various edge-cases. These bugs
typically cause a MediaWiki error page to be shown.
If you encounter an error, please report it on Bugzilla and tag with it the
'HHVM' keyword.
We're not done yet, but this is an important milestone. The roll-out of
HHVM as a beta feature caps many months of hard work from many developers,
both salaried and volunteer, from the Wikimedia Foundation, Wikimedia
Deutschland, and the broader Wikimedia movement. I want to take this
opportunity to express my appreciation to the following individuals, listed
in alphabetical order:
Aaron Schulz, Alexandros Kosiaris, Brad Jorsch, Brandon Black, Brett
Simmers, Bryan Davis, Chad Horohoe, Chris Steipp, Erik Bernhardson, Erik
Möller, Faidon Liambotis, Filippo Giunchedi, Giuseppe Lavagetto, Greg
Grossmeier, Jack McBarn, Katie Filbert, Kunal Mehta, Mark Bergsma, Max
Semenik, Niklas Laxström, Rob Lanphier, and Tim Starling.
More good things to come! :)
