Re: [Wikitech-l] Start of Outreachy round 12

[Tony Thomas]

Hello all,

Standard announcement by the Gnome team to spread word about Outreachy'12
and Google Summer of Code 2016 programs.

** https://wiki.gnome.org/Outreachy/2016/MayAugust/SpreadTheWord **

Free and Open Source Software (FOSS) is software that gives the user the
freedom to use, share, study, and improve it. FOSS contributors believe
that this is the best way to develop software because it benefits society,
creates a fun collaborative community around a project, and allows anyone
to make innovative changes that reach many people.

Google Summer of Code is a global program that offers students stipends to
write code for over one hundred participating FOSS organizations.
Applicants must be able to make the project their primary focus during the
summer. Participants work remotely from home, while getting guidance from
an assigned mentor and collaborating within their project’s community.
Organizations participating in Google Summer of Code will be announced on
February 29. The application deadline for Google Summer of Code is March
25, and the program dates are May 23 to August 23. The stipend for the
program is $5,500 (USD).

http://summerofcode.withgoogle.com/

In an effort to improve diversity in FOSS, a number of organizations are
offering similar remote and mentored Outreachy internships through a
program organized by Software Freedom Conservancy. These internships are
open internationally to women (cis and trans), trans men, and genderqueer
people. Also, the internships are open in the U.S. to all Black/African
American, Hispanic/Latin@, American Indian, Alaska Native, Native Hawaiian,
and Pacific Islander people. Applicants must be available for full-time,
40-hours a week, internships.

The application deadline for Outreachy is March 22, and the internship
dates are May 23 to August 23. The stipend for the program is also $5,500
(USD). Unlike in Google Summer of Code, participants do not need to be
students and non-coding projects are available. In addition to coding,
projects include such tasks as graphic design, user experience design,
documentation, bug triage and community engagement.

http://outreachy.org

To apply for either program, you need to connect with a participating
organization early, select a project you want to work on, make a few
relevant contributions with the help of a mentor, and create a project plan.

Please consider applying for Google Summer of Code or Outreachy, encourage
someone else to apply, or help spread the word by forwarding this message
to any interested university and community groups. To learn more, please
join mentors, coordinators, and alums of Outreachy for a Twitter chat with
a hashtag #OutreachyChat at 4pm UTC on March 1 (11am EST) or at 2am UTC on
March 2 (9pm EST on March 1).

Thanks,
Tony Thomas 
ThinkFOSS 

www.thomastony.me


On Mon, Feb 22, 2016 at 2:34 PM, Sumit Asthana 
wrote:
>
> Greetings,
>
> Wikimedia is a mentoring organization for Outreachy round 12 and the
application period is now open[1]. More details can be found out on the
program page[2].
>
> We have a lot of project ideas in the Possible-Tech-Projects board[3],
where students can look for ideas.
>
> Some of them have a well defined scope with micro-tasks and ready to be
featured, while many others require your love.
>
> Do consider stepping forward and adding yourself as a mentor if you feel
you could help move any of the projects forward, especially in the
"Discussion" and "Missing mentors" column. A lot of projects in the
"Missing mentors" column have also been recently added, which are Community
wishlist items, and stand a good chance of being featured.
>
> Your comments would be greatly appreciated in shaping these ideas into
featured projects for the students.
>
> Also, if you know of other projects/ideas which could be a good fit for a
3 month GSoC/Outreachy internship, feel free to add them to the board.
>
> [1] - https://outreachy.gnome.org/?q=program_home=6
> [2] - https://www.mediawiki.org/wiki/Outreachy/Round_12
> [3] - https://phabricator.wikimedia.org/tag/possible-tech-projects/
>
>
> -Thank You!
> -Sumit
> -Co-organizer of Outreachy 12 alongwith Tony Thomas
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] RFC: Defining a policy for REST API result format versioning / negotiation

[Gabriel Wicke]

At the conclusion of the Final Comment Period, the Architecture
Committee today decided to accept the policy as summarized in my last
mail:

- Use `Accept` headers for format negotiation.
- Strongly encourage users to explicitly request a specific format
version, and update the default format promptly.

We will now document and implement this policy. The first use of
content negotiation will be an upcoming change in Parsoid's HTML
format.

Thank you for your input,

Gabriel


On Wed, Feb 17, 2016 at 3:36 PM, Gabriel Wicke  wrote:
> The IRC discussion just finished, thanks to everybody who
> participated! You can read a full log on the task [1]. Here is a short
> summary:
>
> == Question 1: How to request a specific response format ==
>
> Overall there was a slight preference for using the Accept header over
> query strings for format negotiation. It was noted that support for
> query strings can be added additionally at a later point.
>
> == Question 2: What to do if no format was specified ==
>
> The main question in the discussion was whether strong encouragement
> will be enough to persuade clients to explicitly specify a format
> version. A common concern was that clients without explicit version in
> the request won't pay attention to announcements either, and will only
> find out when things break.
>
> There was consensus for starting with strong encouragement and quick
> default changes. If most clients continue to omit explicit versions in
> their requests, then we can reconsider *forcing* clients to supply a
> version.
>
> == Next steps ==
>
> The Architecture Committee will officially decide this matter based on
> the discussion at next Wednesday's meeting.
>
> Gabriel
>
> [1]: https://phabricator.wikimedia.org/T124365#2036959
>
> On Mon, Feb 15, 2016 at 7:41 PM, Gabriel Wicke  wrote:
>> We will discuss options for REST API response format versioning and
>> -negotiation in Wednesday's RFC meeting:
>>
>> Topic: https://phabricator.wikimedia.org/T124365
>> Time: Wednesday 22:00 UTC (2pm PST)
>> Location: #wikimedia-office IRC channel
>>
>> This RFC will then enter its one-week Final Comment Period, after
>> which the Architecture Committee will decide based on the discussion.
>>
>> I'm looking forward to your input on the task or IRC.
>>
>> Gabriel
>>
>> On Thu, Jan 21, 2016 at 4:29 PM, Gabriel Wicke  wrote:
>>> Hi,
>>>
>>> we are considering a policy for REST API end point result format
>>> versioning and negotiation. The background and considerations are
>>> spelled out in a task and mw.org page:
>>>
>>> https://phabricator.wikimedia.org/T124365
>>> https://www.mediawiki.org/wiki/Talk:API_versioning
>>>
>>> Based on the discussion so far, have come up with the following
>>> candidate solution:
>>>
>>> 1) Clearly advise clients to explicitly request the expected mime type
>>> with an Accept header. Support older mime types (with on-the-fly
>>> transformations) until usage has fallen below a very low percentage,
>>> with an explicit sunset announcement.
>>>
>>> 2) Always return the latest content type if no explicit Accept header
>>> was specified.
>>>
>>> We are interested in hearing your thoughts on this.
>>>
>>> Once we have reached rough consensus on the way forward, we intend to
>>> apply the newly minted policy to an evolution of the Parsoid HTML
>>> format, which will move the data-mw attribute to a separate metadata
>>> blob.
>>>
>>> Gabriel Wicke
>>
>>
>>
>> --
>> Gabriel Wicke
>> Principal Engineer, Wikimedia Foundation
>
>
>
> --
> Gabriel Wicke
> Principal Engineer, Wikimedia Foundation



-- 
Gabriel Wicke
Principal Engineer, Wikimedia Foundation

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

Re: [Wikitech-l] 1.27.0-wmf.14 on hold

[Chad]

On Wed, Feb 17, 2016 at 5:35 PM Chad  wrote:

> On Tue, Feb 16, 2016 at 12:23 PM Antoine Musso  wrote:
>
>> Le 16/02/2016 18:20, Chad a écrit :
>> > Hi all,
>> >
>> > Holding deploy now
>> > There is a bug with save times
>> > See this task for more[0]
>> >
>> > -Chad
>>
>> Note: the branch has been cut already on Feb 16th around 15:00 UTC.
>>
>>
> Update: we deployed to testwiki yesterday, mainly so we could populate
> the l10n caches for the new branch.
>
> We're still holding back wmf.14 from the remaining wikis while the problem
> is investigated.
>
>
Sorry for not updating earlier in the week with the current status. There
was a little ambiguity if we were holding this week or not. The roadmap
on mw.org reflects reality (dates are off for wmf.14 because templates :):

https://www.mediawiki.org/wiki/MediaWiki_1.27/Roadmap

wmf.14 is currently on group0 and group1, which is all wikis except the
Wikipedias. wmf.14 will go to the Wikipedias tomorrow as scheduled.

We'll proceed with our usual cadence, starting with wmf.15, next week.
It'll end up having a 2 week delta of changes because we lost a week in
the process.

Thanks for your patience everyone, the trains will be running on time again
shortly.

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

Re: [Wikitech-l] ORES extension soon be deployed, help us test it

[Amir Ladsgroup]

Hey all,
ORES extension is now enabled in beta cluster, in Wikipedia projects only,
you can enable it in your beta features tab [1] and then check it out in
RecentChanges or watchlist, etc. [2]

[1]: For English:
http://en.wikipedia.beta.wmflabs.org/wiki/Special:Preferences#mw-prefsection-betafeatures
[2]: An example:
http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:RecentChanges=1

Best

On Tue, Feb 23, 2016 at 7:48 PM Amir Ladsgroup  wrote:

> It's done, the patch is merged now and we should have it the beta cluster.
> The only thing here is caching. It seems people can't enable it because
> betafeatures special page is cached.
>
> Best
>
> On Mon, Feb 22, 2016 at 5:05 AM Gergo Tisza  wrote:
>
>> On Sun, Feb 21, 2016 at 10:06 AM, Amir Ladsgroup 
>> wrote:
>>
>> > We should make a patch like this
>> > https://gerrit.wikimedia.org/r/#/c/269478/
>> > but for testwiki AFAIK.
>> >
>>
>> testwiki is in the production cluster. For the beta cluster, make a
>> similar
>> patch but change the *-labs files instead. You can find the list of beta
>> cluster wikis here:
>> https://noc.wikimedia.org/conf/highlight.php?file=all-labs.dblist
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Today's RFC meeting on IRC: Standardise on how to access/register JavaScript interfaces

[Jon Robson]

Thanks for the reminder :)


On Wed, Feb 24, 2016 at 1:11 PM, Roan Kattouw  wrote:
> My apologies for the short notice. Normally we announce these more than one
> hour in advance, but I forgot.
>
> In today's RFC meeting, we will discuss the following RFC:
>
> * Standardise on how to access/register JavaScript interfaces
> 
>  >
>
> The meeting will be on the IRC channel #wikimedia-office on
> chat.freenode.net at the following time:
>
> * UTC: Wednesday 22:00
> * US PST: Wednesday 14:00
> * Europe CET: Wednesday 23:00
> * Australia AEDT: Thursday 09:00
>
> Roan
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon

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

[Wikitech-l] Today's RFC meeting on IRC: Standardise on how to access/register JavaScript interfaces

[Roan Kattouw]

My apologies for the short notice. Normally we announce these more than one
hour in advance, but I forgot.

In today's RFC meeting, we will discuss the following RFC:

* Standardise on how to access/register JavaScript interfaces

>

The meeting will be on the IRC channel #wikimedia-office on
chat.freenode.net at the following time:

* UTC: Wednesday 22:00
* US PST: Wednesday 14:00
* Europe CET: Wednesday 23:00
* Australia AEDT: Thursday 09:00

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

[Wikitech-l] 2016-02-24 Scrum of Scrums meeting notes

[Grace Gellerman]

https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-02-24

= 2016-02-24 =

== Technology ==

=== Analytics ===
* '''Blocking''': (nobody we know)
* '''Blocked''': (on nothing)
* '''Updates''':
** Upgraded to CDH 5.5, comes with lots of improvements for those using the
Hadoop cluster:
http://www.cloudera.com/documentation/enterprise/latest/topics/cdh_rn_new_in_550.html
** Internally released data that estimates the number of Unique Devices
hitting each of our domains, using the Last Access cookie.  This is a major
release, and it's available in the wmf database in hive, in the
last_access_uniques_daily table.
** Fixed handling of uri-encoded page titles in the pageview API

=== Architecture ===
* '''Blocking''':
** ???
* '''Blocked''':
** ???
* '''Updates''':
** ???

=== Performance ===
* '''Blocking''':
** ???
* '''Blocked''':
** ???
* '''Updates''':
** ???

=== Release Engineering ===
* '''Blocking''':
** https://phabricator.wikimedia.org/T111259
** Update train email as to why stalled
* '''Blocked''':
** None
* '''Updates''':
** AQS deployed via Scap3, (hooray \o/ +1) ready for new services w/new
version
** Phabricator updates happened, puppet work continues
** Train (still) not running wmf.14 on testwiki and that's all

=== Research ===
* '''Blocking''':
** nothing we know of
* '''Blocked''':
** blocked on ops for ORES in production
*** also blocks deployment of ORES extension to fawiki and wikidata
*** halfak would like to engage with ops - could someone contact him?
* '''Updates''':
** none

=== Security ===
* '''Blocking''':
** ???
* '''Blocked''':
** ???
* '''Updates''':
** Working through lots of security bugs
** PageViewInfo review in progress


=== Services ===
* '''Blocking''':
** ???
* '''Blocked''':
** ???
* '''Updates''':
** ???

=== Technical Operations ===
* '''Blocking''':
** ???
* '''Blocked''':
** ???
* '''Updates''':
** ???

== Product ==
=== Community Tech ===
* '''Blocking''':
** ???
* '''Blocked''':
** ???
* '''Updates''':
** ???

=== Discovery ===
* '''Blocking''':
** none afaik
* '''Blocked''':
** Would like Ops input for https://phabricator.wikimedia.org/T126730 (caching
model for WDQS)
** Would like Sec review on SVG sanitizer JS lib
** Would like Sec review on Schema validator php lib
* '''Updates''':
** Preparing to switch completion suggester into production (March)
** A number of new interesting graphs at http://discovery.wmflabs.org/ e.g.
http://discovery.wmflabs.org/metrics/#failure_langproj,
http://discovery.wmflabs.org/portal/#browser_breakdown
** Not much new, mostly bugfixes, tweaks and maintenance
 Graphs 
** Pageview API graphs getting popular


=== Editing ===
 Collaboration 
* '''Blocking''':
** External Store - In progress.  Will soon enable External Store on Beta
Cluster as a pre-requisite for this.  If you want to look/give feedback on
the Beta change, see https://phabricator.wikimedia.org/T95871
* '''Blocked''':
** Flow dumps on dumps.wikimedia.org:
https://phabricator.wikimedia.org/T119511
** Schema change to make a column NOT NULL in production:
https://phabricator.wikimedia.org/T122111#2050844
* '''Updates''':
** Enabled Echo cross-wiki notifications feature on initial wave of wikis.
Good feedback so far.
** Working on some issues with Flow board moves.
** Also, not a Collaboration team thing, but we've asked for feedback on
some Code of Conduct proposed changes:
https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#Suggested_changes

 Language 
* '''Blocking''':
** None
* '''Blocked''':
** None
* '''Updates''':
**

 Multimedia 
* '''Blocking''':
** ???
* '''Blocked''':
** ???
* '''Updates''':
** ???

 Parsing 
* '''Blocking''':
** None?
* '''Blocked''':
** None
* '''Updates''':
** Templatedata based serialization being deployed today (
https://phabricator.wikimedia.org/T111674 and
https://phabricator.wikimedia.org/T104599 )
** Kunal and Ori have been investigating
https://phabricator.wikimedia.org/T124356 ... Ori might have made some
headway there.
*** Filed https://phabricator.wikimedia.org/T127757 to fix getText()
semantics to prevent this kind of sneaky bugs in the future.
** Heads up for release engineering:
https://phabricator.wikimedia.org/T111259 bit us once more recently.

 VisualEditor 
* '''Blocking''':
** None known.
* '''Blocked''':
** Waiting on Design Research availability for user testing of Single Edit
Tab integration
* '''Updates''':
** Single Edit Tab went to Hungarian Wikipedia yesterday; now waiting on
user feedback.
** Some improvements to OOUI; note the breaking change for wmf.15+ (no
known issues in gerrit master code).
** Last week we said we'd update on assessing the performance impact of
OOUI on all read pages; this is not firm yet, but appears to be a trivial
additional cost.

=== Fundraising Tech ===
* No blockers/blocking
* Investigating anomalies
* Improving CiviCRM reporting
* Testing backup processor improvements
* Further Latin America processor work

=== Reading ===

 

Re: [Wikitech-l] pt.wikimedia.org - database naming

[Legoktm]

Hi,

On 02/24/2016 06:18 AM, Antoine Musso wrote:
> Given most of the useful data/history has been exported, I would suggest
> to rename on WMF cluster the ptwikimedia DB to something like
> ptwikimedia_old or even just archive a dump of it and drop it.
> 
> Then create a new ptwikimedia and import the external db there.

I think reusing the "ptwikimedia" db name would be ideal. My only
concern with doing so is that it might be in databases somewhere, but I
checked CentralAuth and there are no ptwikimedia entries, so at least
that will be fine.

-- Legoktm

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

Re: [Wikitech-l] pt.wikimedia.org - database naming

[Jeremy Baron]

On Wed, Feb 24, 2016 at 11:09 AM, John  wrote:
> I dont want to come across as a dick, but renaming this wiki shouldn't be
> overly difficult. Worst case you dump the database and re-import under a
> new name. Since this is a non-active wiki all of the normal overhead isnt
> there.

yes, it should be a bit simpler because it is inactive.

but AIUI, the big hurdle is not in renaming the DB but in renaming the
externalstore. (and idk how that's laid out so I'll leave it to others
to elaborate)

-Jeremy

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

Re: [Wikitech-l] pt.wikimedia.org - database naming

[John]

I dont want to come across as a dick, but renaming this wiki shouldn't be
overly difficult. Worst case you dump the database and re-import under a
new name. Since this is a non-active wiki all of the normal overhead isnt
there.



On Wed, Feb 24, 2016 at 10:42 AM, Chad  wrote:

> On Wed, Feb 24, 2016 at 7:23 AM Jaime Crespo 
> wrote:
>
> > > I would suggest
> > > to rename on WMF cluster the ptwikimedia DB to something like
> > > ptwikimedia_old
> >
> > If you want this, I hope the users will have the patience to wait for
> > when the renaming wikis bug will be solved in 2034.
> >
> > Or, you know, we can create *now* a new wiki with a new name that most
> > users will not notice (it will not affect the domain name,
> > pt.wikimedia.org).
> >
> >
> But there's not a wiki running there, just an old database. I imagine we
> could just rename the database (and associated external storage?).
>
> The move off-cluster predates RESTBase and Elasticsearch so no worries
> there. Any old memcached keys have long since expired too.
>
> -Chad
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] pt.wikimedia.org - database naming

[Chad]

On Wed, Feb 24, 2016 at 7:23 AM Jaime Crespo  wrote:

> > I would suggest
> > to rename on WMF cluster the ptwikimedia DB to something like
> > ptwikimedia_old
>
> If you want this, I hope the users will have the patience to wait for
> when the renaming wikis bug will be solved in 2034.
>
> Or, you know, we can create *now* a new wiki with a new name that most
> users will not notice (it will not affect the domain name,
> pt.wikimedia.org).
>
>
But there's not a wiki running there, just an old database. I imagine we
could just rename the database (and associated external storage?).

The move off-cluster predates RESTBase and Elasticsearch so no worries
there. Any old memcached keys have long since expired too.

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

Re: [Wikitech-l] pt.wikimedia.org - database naming

[Jaime Crespo]

> I would suggest
> to rename on WMF cluster the ptwikimedia DB to something like
> ptwikimedia_old

If you want this, I hope the users will have the patience to wait for
when the renaming wikis bug will be solved in 2034.

Or, you know, we can create *now* a new wiki with a new name that most
users will not notice (it will not affect the domain name,
pt.wikimedia.org).

On Wed, Feb 24, 2016 at 3:18 PM, Antoine Musso  wrote:
> Le 24/02/2016 14:56, Waldir Pimenta a écrit :
>> Assuming there's no easy way to merge the databases, we are fine with
>> dropping the old db. I believe most content was imported to the current
>> wiki at the time of the migration, see
>> https://phabricator.wikimedia.org/T25537. An xml dump was used, not an SQL
>> one, so I suppose stuff like logs may not have been preserved, but in any
>> case it's not critical that we preserve all that historical info. I mean,
>> it would certainly be nice, but we can live without it.
>>
>> Or we could use the pt2wikimedia, as that would allow future archeologists
>> to recover the data from the beginning of the wiki :) Either option is fine.
>
> Hello,
>
> The ptwikimedia database being from 2012, I don't think there is much
> point in attempting to upgrade its schema, much less attempting to merge
> in the external db in.
>
> Given most of the useful data/history has been exported, I would suggest
> to rename on WMF cluster the ptwikimedia DB to something like
> ptwikimedia_old or even just archive a dump of it and drop it.
>
> Then create a new ptwikimedia and import the external db there.
>
>
> I am an idealist, but I am afraid introducing a scheme like
> 2 is asking for various exceptions to be added in
> various code and will cause a nasty technical debt down the road.
>
> My 0.02 €
>
> --
> Antoine "hashar" Musso
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Jaime Crespo


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

Re: [Wikitech-l] pt.wikimedia.org - database naming

[Antoine Musso]

Le 24/02/2016 14:56, Waldir Pimenta a écrit :
> Assuming there's no easy way to merge the databases, we are fine with
> dropping the old db. I believe most content was imported to the current
> wiki at the time of the migration, see
> https://phabricator.wikimedia.org/T25537. An xml dump was used, not an SQL
> one, so I suppose stuff like logs may not have been preserved, but in any
> case it's not critical that we preserve all that historical info. I mean,
> it would certainly be nice, but we can live without it.
> 
> Or we could use the pt2wikimedia, as that would allow future archeologists
> to recover the data from the beginning of the wiki :) Either option is fine.

Hello,

The ptwikimedia database being from 2012, I don't think there is much
point in attempting to upgrade its schema, much less attempting to merge
in the external db in.

Given most of the useful data/history has been exported, I would suggest
to rename on WMF cluster the ptwikimedia DB to something like
ptwikimedia_old or even just archive a dump of it and drop it.

Then create a new ptwikimedia and import the external db there.


I am an idealist, but I am afraid introducing a scheme like
2 is asking for various exceptions to be added in
various code and will cause a nasty technical debt down the road.

My 0.02 €

-- 
Antoine "hashar" Musso


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

Re: [Wikitech-l] [GSoC2016] Automatically create a summary of wiki articles

[Prateek Saxena]

I don't know anything about document summarization, but from a
Hovercards perspective, it'd be more helpful to have a contextual
summary than a complete one. For example:

Person A leader of the B movement
studied in University C in 1923.

Then, apart from the Hovercard having a basic summary of University C,
it would also be nice to see:

 University C saw a lot of opposition to
 movement B during the 1920's.

I am not sure the research you linked to aims to do this though.

Also, the paper used the data in the infobox to figure out important
parts of the document. Using Wikidata alongside this might make it
easier to grasp the concepts that are being talked about.

CCing Aaron and Magnus who would know more about all of this.


—prtksxna

On Mon, Feb 22, 2016 at 10:34 PM, Ultimate Supreme
 wrote:
> Sorry, here is the correct link:
> http://lms.comp.nus.edu.sg/sites/default/files/publication-attachments/acl09-yesr.pdf
>
> On Mon, Feb 22, 2016 at 9:37 PM, Andre Klapper 
> wrote:
>
>> On Mon, 2016-02-22 at 20:19 +0530, Ultimate Supreme wrote:
>> > Though there has been some independent research
>> > > > yesr.pdf>
>>
>> "The requested page "/sites/default/files/publication.../acl09-
>> yesr.pdf" could not be found."
>>
>> Cheers,
>> andre
>> --
>> Andre Klapper | Wikimedia Bugwrangler
>> http://blogs.gnome.org/aklapper/
>>
>>
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
>
> --
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

Re: [Wikitech-l] pt.wikimedia.org - database naming

[Waldir Pimenta]

Assuming there's no easy way to merge the databases, we are fine with
dropping the old db. I believe most content was imported to the current
wiki at the time of the migration, see
https://phabricator.wikimedia.org/T25537. An xml dump was used, not an SQL
one, so I suppose stuff like logs may not have been preserved, but in any
case it's not critical that we preserve all that historical info. I mean,
it would certainly be nice, but we can live without it.

Or we could use the pt2wikimedia, as that would allow future archeologists
to recover the data from the beginning of the wiki :) Either option is fine.

On Wed, Feb 24, 2016 at 12:13 PM, This, that and the other <
at.li...@live.com.au> wrote:

> Why not just delete the old ptwikimedia site and put the new one in its
> place, using the same dbname?
>
> The old wiki is inaccessible, since pt.wikimedia.org redirects offsite,
> so it's unclear if the old DB even needs to be preserved. And presumably
> any configuration bits that refer to ptwikimedia will still be relevant to
> the new site.
>
> If for some reason that is not feasible, I guess pt2wikimedia is
> acceptable, though only as a last resort. As I've said before, there really
> needs to be a better way to rename wikis without wasting hours of
> everyone's time...
>
> TTO
>
> --
> "Alex Monk"  wrote in message
> news:CALMPGzX_E4ML0xD2A_2vTRZ+2a+nWtpC9KkJe58x=mdg-uo...@mail.gmail.com...
>
>
> Hi all,
>
> A request has come up (https://phabricator.wikimedia.org/T126832) to
> re-create pt.wikimedia.org on the wikimedia cluster. Unfortunately it was
> previously hosted there and so the 'ptwikimedia' database name is already
> taken.
> Since database renaming does not really appear to be an option, does anyone
> have any objections to using 'pt2wikimedia' (or similar, suggestions
> welcome) instead for the new wiki? I know this doesn't fit the existing
> pattern so I'm unsure about just going ahead without asking for input from
> a wider audience.
>
> Alex
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] pt.wikimedia.org - database naming

[This, that and the other]

Why not just delete the old ptwikimedia site and put the new one in its place, 
using the same dbname?


The old wiki is inaccessible, since pt.wikimedia.org redirects offsite, so it's 
unclear if the old DB even needs to be preserved. And presumably any 
configuration bits that refer to ptwikimedia will still be relevant to the new 
site.


If for some reason that is not feasible, I guess pt2wikimedia is acceptable, 
though only as a last resort. As I've said before, there really needs to be a 
better way to rename wikis without wasting hours of everyone's time...


TTO

--
"Alex Monk"  wrote in message 
news:CALMPGzX_E4ML0xD2A_2vTRZ+2a+nWtpC9KkJe58x=mdg-uo...@mail.gmail.com...


Hi all,

A request has come up (https://phabricator.wikimedia.org/T126832) to
re-create pt.wikimedia.org on the wikimedia cluster. Unfortunately it was
previously hosted there and so the 'ptwikimedia' database name is already
taken.
Since database renaming does not really appear to be an option, does anyone
have any objections to using 'pt2wikimedia' (or similar, suggestions
welcome) instead for the new wiki? I know this doesn't fit the existing
pattern so I'm unsure about just going ahead without asking for input from
a wider audience.

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




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