Hi All,
I plan to work on the project to implement VERP ( Variable Envelope
Return Path ) functionality to MediaWiki Email system. The project is
originally a manifest of bug
46440<https://bugzilla.wikimedia.org/show_bug.cgi?id=46640>.
Where the developers came with the idea of implementing it this summer, as
the entire infrastructure of mail is being rebuilt. I found the project
interesting as I had done a few Networking courses in my 10th class, out of
my interest and VERP could cut down a lot of resource wastage. The
implementation, includes a MW development side, to create a new API to
implement VERP and a System-Ops component - to route VERP bounces to a
script and call the new API.
Jeff Green is mentoring from the Sys-Ops side and Kunal Mehta
(legoktm) from the MW development side. We have already started by building
up the development environment, with two VBoxes, one acting as the
MediaWiki server and another to act as a router, routing all mails in the
channel to valid/invalid cases so that bounces can be observed. We are
planing to move it to labs, once its up.
I had been part of the MediaWiki community since August 2013, and
it's the community to which I could do my first Open Source Contribution. I
would be more than delighted to do a GSoC with the same community.
Currently, I am doing my second year in Computer Science Engineering at
Amrita Vishwa Vidhyapeetham, Kerala, India.
My Proposal:-
https://www.mediawiki.org/wiki/User:01tonythomas/mediawiki_VERP
UserPage :- https://www.mediawiki.org/wiki/User:01tonythomas
Gerrit Changes: Gerrit owner:
01tonythomas<https://gerrit.wikimedia.org/r/#/q/owner:%2201tonythomas+%253C01tonythomas%…>
Please go through my proposal, and comment in where all I need to
improve.
Tony Thomas <http://tttwrites.in>
FOSS@Amrita <http://foss.amrita.ac.in>
*"where there is a wifi,there is a way"*
Hey all,
I recently had a new repository created; and I wanted to create some jobs
for it.
I dutifully created and had merged:
https://gerrit.wikimedia.org/r/#/c/115968/https://gerrit.wikimedia.org/r/#/c/115967/
Hashar told me I then needed to follow the instructions on [1] to push the
jobs to jenkins. Running the script myself was only pain; it kept erroring
out while trying to create the job. Marktraceur managed to create the jobs
after much "kicking down the door" aka running the script multiple times.
It appears that the problem is that
https://integration.mediawiki.org/ci/createItem?name=mwext-FundraisingChart…
to
https://integration.mediawiki.org/?...
So that's a problem? We're still not sure why Mark was able to create the
jobs with perseverance though.
Another problem that I'm seeing is in responsibilities -- supposedly only
jenkins admins (wmf developers) can submit jobs (and then only when it
works). And then, only people with root on galium can apply the Zuul
configs. To me this is clearly not something the average developer is
supposed to be doing.
Would it make sense to have QChris / ^demon create the standard jobs when
they create the repository?
[1]
https://www.mediawiki.org/wiki/Continuous_integration/Tutorials/Adding_a_Me…
~Matt Walker
Wikimedia Foundation
Fundraising Technology Team
*Hi*
*How do I build a python bot/script with JavaScript for the frontend
(ideally as Wikisouorce gadget <https://www.mediawiki.org/wiki/Gadget>).*
*Project is for gsoc2014. So it should be something which can be live on
wikisource gadgets.*
*Thanks*
*---*
*Rohit Dua*
*8ohit.dua*
Hello All,
As should come as no surprise given the number of advance warnings sent
over the past couple months, the time for migration of the tool labs
project from pmtpa to eqiad is at hand!
[This email applies to tools on the Tool Labs /only/; if you have
projects in labs, then you want to refer to the instructions given by
Andrew Bogott in his previous email.]
For roughly the following two weeks maintainers are encouraged to
migrate their tools to the new eqiad datacenter by themselves. At the
end of that "free" migration period, we will migrate the remaining tools
automatically but keep them disabled until the maintainers have the
opportunity to look them over.
You can find status and notes about the Tool Labs migration at:
https://wikitech.wikimedia.org/wiki/Tool_Labs/Migration_to_eqiad
== Migrating Tools ==
Scripts have been provided to ease the transition. From your *user*
account on tools-login.wmflabs.org, you can do:
$ migrate-tool <toolname>
This will prepare your tool for migration, and schedule the data copy.
More details are provided on-screen. Do this for every tool for which
you are the maintainer. (If there is more than one maintainer, any one
of them can perform the migration).
This will also stop any jobs, webservice or cron entries.
Once the copy is complete (you can check the status of the copy by
issuing the migrate-tool command again) you can issue the following
command from tools-login-eqiad.wmflabs.org:
$ finish-migration <toolname>
this will do the eqiad end of the migration. Please be aware that it
may take some time before the copy is started, as they are queued.
Please also note that, to preserve space and bandwidth, log files are
not copied over (that includes files ending in .out, .err and .log). If
you absolutely need to copy them over, then you can compress them first
with gzip.
*** IMPORTANT ***
Migrating tools with those scripts carefully preserves all data IF IT IS
ONLY ATTEMPTED ONCE. If you run into troubles or issues, please contact
me, and we'll fix you up. They will not allow you to try again if
something went wrong unless you work hard at it. Don't.
== Migrating Users ==
You can migrate the contents of your home in pretty much the same way:
$ migrate-user
This will schedule a copy of your home directory to eqiad. There is no
second half of the script to run once it is complete.
== Advanced Users ==
If there are details you want to handle manually, you can 'ssh eqiad'
from either tools-login or tools-dev (that includes being able to scp).
== In case of panic ==
Do not break glass; come on freenode IRC to the #wikimedia-labs channel
and help can be found. :-)
-- Marc
Minutes and slides from Friday's quarterly review of the Foundation's
Growth team are now available at
https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r…
.
On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller <erik(a)wikimedia.org> wrote:
> Hi folks,
>
> to increase accountability and create more opportunities for course
> corrections and resourcing adjustments as necessary, Sue's asked me
> and Howie Fung to set up a quarterly project evaluation process,
> starting with our highest priority initiatives. These are, according
> to Sue's narrowing focus recommendations which were approved by the
> Board [1]:
>
> - Visual Editor
> - Mobile (mobile contributions + Wikipedia Zero)
> - Editor Engagement (also known as the E2 and E3 teams)
> - Funds Dissemination Committe and expanded grant-making capacity
>
> I'm proposing the following initial schedule:
>
> January:
> - Editor Engagement Experiments
>
> February:
> - Visual Editor
> - Mobile (Contribs + Zero)
>
> March:
> - Editor Engagement Features (Echo, Flow projects)
> - Funds Dissemination Committee
>
> We'll try doing this on the same day or adjacent to the monthly
> metrics meetings [2], since the team(s) will give a presentation on
> their recent progress, which will help set some context that would
> otherwise need to be covered in the quarterly review itself. This will
> also create open opportunities for feedback and questions.
>
> My goal is to do this in a manner where even though the quarterly
> review meetings themselves are internal, the outcomes are captured as
> meeting minutes and shared publicly, which is why I'm starting this
> discussion on a public list as well. I've created a wiki page here
> which we can use to discuss the concept further:
>
> https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r…
>
> The internal review will, at minimum, include:
>
> Sue Gardner
> myself
> Howie Fung
> Team members and relevant director(s)
> Designated minute-taker
>
> So for example, for Visual Editor, the review team would be the Visual
> Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker.
>
> I imagine the structure of the review roughly as follows, with a
> duration of about 2 1/2 hours divided into 25-30 minute blocks:
>
> - Brief team intro and recap of team's activities through the quarter,
> compared with goals
> - Drill into goals and targets: Did we achieve what we said we would?
> - Review of challenges, blockers and successes
> - Discussion of proposed changes (e.g. resourcing, targets) and other
> action items
> - Buffer time, debriefing
>
> Once again, the primary purpose of these reviews is to create improved
> structures for internal accountability, escalation points in cases
> where serious changes are necessary, and transparency to the world.
>
> In addition to these priority initiatives, my recommendation would be
> to conduct quarterly reviews for any activity that requires more than
> a set amount of resources (people/dollars). These additional reviews
> may however be conducted in a more lightweight manner and internally
> to the departments. We're slowly getting into that habit in
> engineering.
>
> As we pilot this process, the format of the high priority reviews can
> help inform and support reviews across the organization.
>
> Feedback and questions are appreciated.
>
> All best,
> Erik
>
> [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus
> [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
>
> _______________________________________________
> Wikimedia-l mailing list
> Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
--
Tilman Bayer
Senior Operations Analyst (Movement Communications)
Wikimedia Foundation
IRC (Freenode): HaeB
OK, this was actually meant to have a more descriptive message subject. Ignore the previous message...
----- Original message -----
From: Gryllida
To: wikitech-l
Subject: Fwd: [Bug 7148] Requesting watchlist for changes to category content.
Date: Tue, 04 Mar 2014 13:27:11 +1100
It would seem to me that the Collection extension, which provides 'books' for various sister projects, could be adapted for favorites: 'Book:<Username>' where a user can stick favorite articles and group by sections.
https://www.mediawiki.org/wiki/Extension:Collection
Thoughts?
----- Original message -----
From: bugzilla-daemon(a)wikimedia.org
To: gryllida(a)fastmail.fm
Subject: [Bug 7148] Requesting watchlist for changes to category content.
Date: Sun, 02 Mar 2014 11:43:14 +0000
https://bugzilla.wikimedia.org/show_bug.cgi?id=7148
--- Comment #32 from Subfader ---
I hacked me around this by using favorites and filtering new pages by faved
categories.
Favorites is another thing MW misses...
--
You are receiving this mail because:
You voted for the bug.