Re: [Wikimedia-l] [Wikimedia Announcements] Changes to Product and Technology departments at the Foundation

[Deborah Tankersley]

Hi James,

Does maps also include other rich content like graphs, charts, heat maps
> and other forms of data visualization?


​In reference to your question above, have you had a chance to read through
the email that was sent yesterday, in regards to the Discovery team? [1] We
discussed maps and graphs in that email, but not things like heat maps or
other data visualizations as those are not a part of Discovery's current
annual goals.

Cheers,

Deb

[1] https://lists.wikimedia.org/pipermail/wikimedia-l/2017-June/08.html
​

--
deb tankersley
irc: debt
Product Manager, Discovery
Wikimedia Foundation

On Mon, Jun 12, 2017 at 9:07 AM, James Heilman  wrote:

> Looks like a reasonable change. Glad to see the degree of internal input
> that went into it.
>
> Does maps also include other rich content like graphs, charts, heat maps
> and other forms of data visualization?
>
> Best
> James
>
> On Mon, Jun 12, 2017 at 8:44 AM, Toby Negrin 
> wrote:
>
> > Hi Jan --
> >
> > Thanks for the question. We'll be making a more specific announcement
> this
> > week about the future of the discovery projects. Sadly we don't have a
> lot
> > of new information for maps in particular and will need to do a bit more
> > scenario planning before we talk to the community.
> >
> > As far as focus, most of our "reading" features are actually content
> > created by editors that is consumed by readers and maps is no different.
> > While we don't have specifics as far as the roadmap, both authoring and
> > consumption features are totally in scope.
> >
> > Hope this helps to provide some information (if not clarity :) about how
> we
> > are approaching this.
> >
> > -Toby
> >
> > On Thu, Jun 8, 2017 at 2:21 PM, Jan Ainali  wrote:
> >
> > > 2017-06-07 23:12 GMT+02:00 Toby Negrin :
> > >
> > > >
> > > > The team working on maps, the search experience, and the project
> entry
> > > > portals (such as Wikipedia.org) will join the Readers team. This
> > > > realignment will allow us to build more integrated experiences and
> > > > knowledge-sharing for the end user.
> > > >
> > > Does maps going to readers mean that there will be less focus on
> editors
> > > tools for adding maps to articles and more focus on the readers
> > possibility
> > > to interact with the maps? If so, what is actually in the pipeline for
> > > maps?
> > >
> > > /Jan
> > > ___
> > > Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> > > wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
> > > wiki/Wikimedia-l
> > > New messages to: Wikimedia-l@lists.wikimedia.org
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > 
> > >
> > ___
> > Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> > wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
> > wiki/Wikimedia-l
> > New messages to: Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > 
> >
>
>
>
> --
> James Heilman
> MD, CCFP-EM, Wikipedian
>
> The Wikipedia Open Textbook of Medicine
> ___
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
> wiki/Wikimedia-l
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

[Wikimedia-l] [Wikimedia Announcements] The Signpost – Volume 13, Issue 4 – 9 June 2017

[Wikipedia Signpost]

>From the editors: Signpost status: On reserve power, Help wanted!
http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/
2017-06-09/From_the_editors

News and notes: Global Elections
http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/
2017-06-09/News_and_notes

Arbitration report: Cases closed in the Pacific and with Magioladitis
http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/
2017-06-09/Arbitration_report

Op-ed: Wikipedia's lead sentence problem
http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2017-06-09/Op-ed

Featured content: Three months in the land of the featured
http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/
2017-06-09/Featured_content

In the media: Did Wikipedia just assume Garfield's gender?
http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/
2017-06-09/In_the_media

Recent research: Wikipedia bot wars capture the imagination of the popular
press
http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/
2017-06-09/Recent_research

Technology report: Tech news catch-up
http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/
2017-06-09/Technology_report

Traffic report: Film on Top: Sampling the weekly top 10
http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/
2017-06-09/Traffic_report


Single-page view

http://en.wikipedia.org/wiki/Wikipedia:Signpost/Single



https://facebook.com/wikisignpost

https://twitter.com/wikisignpost

--
*Signpost* team
http://en.wikipedia.org/wiki/Wikipedia:Signpost

___
Please note: all replies sent to this mailing list will be immediately directed 
to Wikimedia-l, the public mailing list of the Wikimedia community. For more 
information about Wikimedia-l:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
___
WikimediaAnnounce-l mailing list
wikimediaannounc...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikimediaannounce-l
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

[Wikimedia-l] [Wikimedia Announcements] Update on Discovery Projects

[Deborah Tankersley]

Hi everybody,

You may have seen the recent communication [1
]
about the product and tech tune-up which went live the week of June 5th,
2017. In that communication, we promised an update on the future of
Discovery projects and we will talk about those in this email.

The Discovery team structure has now changed, but the new teams will still
work together to complete the goals as listed in the draft annual plan.[2]
A summary of their anticipated work, as we finalize these changes, is
below. We plan on doing a check-in at the end of the calendar year to see
how our goals are progressing with the new smaller and separated team
structure.

Here is a list of the various projects under the Discovery umbrella, along
with the goals that they will be working on:

Search Backend

Improve search capabilities:

   -

   Implement ‘learning to rank’ [3] and other advanced machine learning
   methodologies
   -

   Improve support for languages using new analyzers
   -

   Maintain and expand power user search functionality

Search Frontend

Improve user interface of the search results page with new functionality:

   -

   Implement explore similar [4]
   

   -

   Update the completion suggester box [5]
   
   -

   Investigate the usage of a Wiktionary widget for English Wikipedia [6]

Wikidata Query Service

Expand and scale:

   -

   Improve ability to support power features on-wiki for readers
   -

   Improve full text search functionality
   -

   Implement SPARQL federation support

Portal

Create and implement automated language statistics and translation updates
for Wikipedia.org

Analysis

Provide in-depth analytics support:

   -

   Perform experimental design, data collection, and data analysis
   -

   Perform ad-hoc analyses of Discovery-domain data
   -

   Maintain and augment the Discovery Dashboards,[7] which allow the teams
   to track their KPIs and other metrics

Maps

Map support:

   -

   Implement new map style
   -

   Increase frequency of OSM data replication
   -

   As needed, assist with individual language Wikipedia’s implementation of
   mapframe [8] 

Note: There is a possibility that we can do more with maps in the coming
year; we are currently evaluating strategic, partnership, and resourcing
options.

Structured Data on Commons

Extend structured data search on Commons, as part of the structured data
grant [9] via:

   -

   Research and implement advanced search capabilities
   -

   Implement new elements, filters, relationships

Graphs and Tabular Data on Commons

We will be re-evaluating this functionality against other Commons
initiatives such as the structured data grant. As with maps, we will
provide updates when we know more.

We are still working out all the details with the new team structure and
there might be some turbulence; let us know if there are any concerns and
we will do our best to answer them.


Best regards,

Deborah Tankersley, Product Manager, Discovery

Erika Bjune, Engineering Manager, Search Platform

Jon Katz, Reading Product Lead

Toby Negrin, Interim Vice President of Product

Victoria Coleman, Chief Technology Officer


[1] https://www.mediawiki.org/wiki/Wikimedia_Engineering/June_2017_changes

[2]
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2017-2018/Draft

[3] https://en.wikipedia.org/wiki/Learning_to_rank

[4]
https://www.mediawiki.org/wiki/Cross-wiki_Search_Result_Improvements/Testing#A.2FB_test:_Add_.27explore_similar.27_pages_and_categories_for_search_results

[5]
https://www.mediawiki.org/wiki/Extension:CirrusSearch/CompletionSuggester

[6]
https://www.mediawiki.org/wiki/Cross-wiki_Search_Result_Improvements/Testing#A.2FB_test:_Add_Wiktionary_widget_to_search_results_page

[7] https://discovery.wmflabs.org/

[8] https://www.mediawiki.org/wiki/Maps/how_to:_embedded_maps

[9] https://commons.wikimedia.org/wiki/Commons:Structured_data
___
Please note: all replies sent to this mailing list will be immediately directed 
to Wikimedia-l, the public mailing list of the Wikimedia community. For more 
information about Wikimedia-l:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
___
WikimediaAnnounce-l mailing list
wikimediaannounc...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikimediaannounce-l
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: 

Re: [Wikimedia-l] Let's set up a Tor onion service for Wikipedia

[Cristian Consonni]

Hi Faidon,

Thank you for taking the time to respond to this thread.

On 14/06/2017 16:57, Faidon Liambotis wrote:
> [ I didn't see this email from Alec on the thread, was it off-list? ]

[no, it's on the list and in the archive [1] ]

> I've been in touch with Alec and other Tor project members on emails,
> in-person Tor project meetings and videoconferences on multiple
> occasions in the past couple of years (the last one being a couple of
> months ago), so I can speak a little bit about this idea in general, as
> well as EOTK specifically.
> 
> The EOTK stuff are interesting but not really an option for us -- they
> rely on a edge (nginx) server performing content manipulation blindly,
> which is a bad idea for many reasons, security amongst them.
> 
> It is possible and feasible to actually do it properly, by making some
> modifications across our stack (MediaWiki, Varnish/nginx). Just to
> mention a couple of issues: one of them is that we need MediaWiki to
> emit different URLs for e.g.  upload.wikimedia.org resources to point to
> the onion address that we will designate for media. For other resources
> (like gadgets) it may be even more complicated or even impossible.
> Another challenge would be to make Extension:TorBlock aware of the Onion
> connections, so that they can be appropriately blocked, as well as
> figure out what to log as the users' IP address when they edit, if they
> are pre-approved to do so.
> 
> Overall, it's not a super complicated project but not a trivial one
> either. Maybe a couple of months time for a motivated individual, who is
> already familiar with our stack.
> 
> If it wasn't obvious from the above, I have put quite a bit of thought
> into it and that's because I share your sentiments about how this is an
> important feature we should support and provide to our users, in
> alignment with our mission.

Thank you. Also, I never thought that setting up a production service
would be easy. (I mean, a test service that goes down when somebody
sneezes too hard, yeah, it would be easy and I could do that ;-), a
production service no).

> However, it hasn't been a priority for me or my team for these reasons:
> - As long as communities feel so-and-so about Tor overall, and e.g.
>   block edits from Tor users, it's hard to justify us in the Foundation
>   investing more time into it, at the expense of other projects. It
>   feels at odds with our communities' wishes a little bit.

From what I have read from the previous discussions (and in this thread
as well), the main problem that has been raised is related with editing
over Tor for the issues of vandalism, spamming and (more importantly)
sockpuppeting.

I understand that it is natural to consider editing when discussing
about this, but it is a much harder problem. From what I see in this
thread I would say, "let's think about one problem at a time".

> - Accessing our sites over the Tor network *is* possible, regardless of
>   whether we provide an Onion service or not, via exit nodes. An Onion
>   service is more of a security and performance optimization and,
>   perhaps more importantly, a statement of support. Making a statement
>   of support while at the same time communities continue blocking edits
>   over Tor and we keep maintaining Extension:TorBlock, would be a little
>   hypocritical of us, the Wikimedia movement, IMHO.

I disagree, on one hand we can show that from a technical and a
community perspective reading and editing are two different problems, on
the other hand we have being blocking Tor for more than 10 years, so if
somebody wants to call us hypocrites they can already do that.

Also, let me say that my impression from the past discussions is that
some requests (coming from people more knowledgeable about Tor than our
projects) were overlooking how the projects and our community works. I
do not want to disparage anybody, simply point out that it is not
automatic to know how ours projects work.

All said, though, this is not an excuse not to make a step in the right
direction.

As for the statement of support, this is true. This service would be a
statement of support towards Tor, but as for statements:
  * we oppose blocking of Wikipedia by governments;
  * our flagship organization is suing the NSA because it has been
spying on our users;
We are already making statements about what is aligned and what is
against our movement's mission and values.

Also - and this is a response to the remark made by Risker - let me say
that the "dark web" is dark only for the part that we let it be dark.

Any statement you can make about the dark web is probably true about the
web in general. The web is still full of many places where you don't
want to go - and, case in point, possibly even more so in 2001 - but
this is not a good reason not to broadcast our project as much as we can.

The web would be a worse place if this movement and our project didn't
exist and exactly for this reason they need to get on the "dark 

Re: [Wikimedia-l] Let's set up a Tor onion service for Wikipedia

[Kevin Smith]

On Tue, Jun 13, 2017 at 7:12 PM, Risker  wrote:

> I have yet to see any indication in numerous discussions about Tor that I
> have read and/or participated in that our technical geniuses (and I say
> that with warmth and honesty) really give a lot of thought to the legal and
> social implications of providing active support to the dark web.


​My entire experience with Tor has been through human rights activists who
fear for their lives.

It is unclear to me how allowing people, who have legitimate security
concerns, to read and contribute to open knowledge, is "actively supporting
the dark web". ​At least on TV, the "dark web" is a very loaded term.

The proposal (as I understand it) would not allow any Tor user to do
anything other than access our projects. That's different from setting up a
general Tor entry or exit node, which would facilitate other uses.

​Kevin​
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Let's set up a Tor onion service for Wikipedia

[Dariusz Jemielniak]

hi Faidon,

On Wed, Jun 14, 2017 at 4:57 PM, Faidon Liambotis 
wrote:

>
>
> However, it hasn't been a priority for me or my team for these reasons:
> - As long as communities feel so-and-so about Tor overall, and e.g.
>   block edits from Tor users, it's hard to justify us in the Foundation
>   investing more time into it, at the expense of other projects. It
>   feels at odds with our communities' wishes a little bit.
>
>
the reason to think about some use of Tor  for me, considering the mixed
feelings about the technology in our community, would be in the app, and
just for reading. If our app used Tor by default, all users in Turkey would
magically find Wikipedia to work on their phones :)

Facebook app allows Tor, but not by default (because it kills
notifications).

I believe that such a use of Tor would possibly be neutral to many people
who otherwise oppose allowing editing through Tor.

dj
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Let's set up a Tor onion service for Wikipedia

[Brad Jorsch (Anomie)]

On Wed, Jun 14, 2017 at 10:57 AM, Faidon Liambotis 
wrote:

> Just to mention a couple of issues: one of them is that we need MediaWiki
> to emit different URLs for e.g.  upload.wikimedia.org resources to point
> to the onion address that we will designate for media.


That part reminds me a bit of https://phabricator.wikimedia.org/T156847,
which is about outputting different addresses in links for the mobile site
versus the desktop site. The same solution might work for both onion links
and mobile site links.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Let's set up a Tor onion service for Wikipedia

[Faidon Liambotis]

Hi Cristian,

[ I didn't see this email from Alec on the thread, was it off-list? ]

I've been in touch with Alec and other Tor project members on emails,
in-person Tor project meetings and videoconferences on multiple
occasions in the past couple of years (the last one being a couple of
months ago), so I can speak a little bit about this idea in general, as
well as EOTK specifically.

The EOTK stuff are interesting but not really an option for us -- they
rely on a edge (nginx) server performing content manipulation blindly,
which is a bad idea for many reasons, security amongst them.

It is possible and feasible to actually do it properly, by making some
modifications across our stack (MediaWiki, Varnish/nginx). Just to
mention a couple of issues: one of them is that we need MediaWiki to
emit different URLs for e.g.  upload.wikimedia.org resources to point to
the onion address that we will designate for media. For other resources
(like gadgets) it may be even more complicated or even impossible.
Another challenge would be to make Extension:TorBlock aware of the Onion
connections, so that they can be appropriately blocked, as well as
figure out what to log as the users' IP address when they edit, if they
are pre-approved to do so.

Overall, it's not a super complicated project but not a trivial one
either. Maybe a couple of months time for a motivated individual, who is
already familiar with our stack.

If it wasn't obvious from the above, I have put quite a bit of thought
into it and that's because I share your sentiments about how this is an
important feature we should support and provide to our users, in
alignment with our mission.

However, it hasn't been a priority for me or my team for these reasons:
- As long as communities feel so-and-so about Tor overall, and e.g.
  block edits from Tor users, it's hard to justify us in the Foundation
  investing more time into it, at the expense of other projects. It
  feels at odds with our communities' wishes a little bit.

- Accessing our sites over the Tor network *is* possible, regardless of
  whether we provide an Onion service or not, via exit nodes. An Onion
  service is more of a security and performance optimization and,
  perhaps more importantly, a statement of support. Making a statement
  of support while at the same time communities continue blocking edits
  over Tor and we keep maintaining Extension:TorBlock, would be a little
  hypocritical of us, the Wikimedia movement, IMHO.

- Looking at it more broadly, Foundation-wide, if we had to invest
  resources into our Tor support, I think adding Tor support to our
  mobile apps would be a better use of our limited resources.

Hope this helps. Happy to help you move this forward if there are ways
to do so.

Best regards,
Faidon
--
Faidon Liambotis
Principal Engineer, Technical Operations
Wikimedia Foundation

On Wed, Jun 14, 2017 at 04:27:12PM +0200, Cristian Consonni wrote:
> On 07/06/2017 20:24, Alec Muffett wrote:
> > If it helps, I built an betatest onion for Wikipedia and all(?) the
> > Wikimedia Foundation websites using EOTK* a few months ago, and documented
> > the build process at:
> > 
> > https://github.com/alecmuffett/eotk/blob/master/docs.d/RUNBOOK.md
> > 
> > A basic test onion takes about 5..10 minutes to set up on Ubuntu or
> > OSX/Homebrew.
> > 
> > A scalable full production loadbalanced deployment on some kind of cloud 
> > orse
> > server(s) should take a day or two, plus time to buy an Onion SSL
> > Certificate where appropriate.
> 
> Thanks Alec.
> 
> I would also point out the offer you made in a tutorial video for EOTK[1]:
> 
> "If anyone from Wikipedia or Wikimedia is watching this video I would
> gladly help you guys set one of this up officially because it is really
> cool"
> 
> It is. It also useful, mission-aligned, and important.
> 
> So, please read my proposal as "Take this offer from Alec Muffett"
> 
> Cristian
> 
> [1]: https://www.youtube.com/watch?v=HNJaMNVCb-U
> 
> ___
> Wikimedia-l mailing list, guidelines at: 
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
> https://meta.wikimedia.org/wiki/Wikimedia-l
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
> 

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Let's set up a Tor onion service for Wikipedia

[Cristian Consonni]

Hi,

On 14/06/2017 04:12, Risker wrote:
> [...] Setting this up is not a
> technical "problem" to be solved (which is essentially what Phabricator is
> for). I will again reinforce: it's a social and ethical issue, and only
> once that is resolved would it be time to consider it a "technical
> problem".

It is also not social problem if we are just talking about reading and
writing only for people who already have IF block exemption, IMHO.

Cristian


___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Let's set up a Tor onion service for Wikipedia

[Cristian Consonni]

On 07/06/2017 20:24, Alec Muffett wrote:
> If it helps, I built an betatest onion for Wikipedia and all(?) the
> Wikimedia Foundation websites using EOTK* a few months ago, and documented
> the build process at:
> 
> https://github.com/alecmuffett/eotk/blob/master/docs.d/RUNBOOK.md
> 
> A basic test onion takes about 5..10 minutes to set up on Ubuntu or
> OSX/Homebrew.
> 
> A scalable full production loadbalanced deployment on some kind of cloud orse
> server(s) should take a day or two, plus time to buy an Onion SSL
> Certificate where appropriate.

Thanks Alec.

I would also point out the offer you made in a tutorial video for EOTK[1]:

"If anyone from Wikipedia or Wikimedia is watching this video I would
gladly help you guys set one of this up officially because it is really
cool"

It is. It also useful, mission-aligned, and important.

So, please read my proposal as "Take this offer from Alec Muffett"

Cristian

[1]: https://www.youtube.com/watch?v=HNJaMNVCb-U

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] [Wikimedia-genealogy] Wikimedia genealogy and historical research software - a proposal for HRE

[Michael Maggs]

Hi Dan, thanks your message, and apologies for the delay in replying.

History Research Environment (HRE) [1] is a community project to create 
a free platform-independent application for the serious amateur or 
professional historical researcher.  The proposed software will be 
primarily focused on genealogical research, including researchers who 
are currently reliant upon the now-discontinued program The Master 
Genealogist (TMG) [2].  In addition, HRE is planned to handle a very 
wide range of other historical and cultural research needs [3].


With the demise of TMG in 2014 the genealogical community lost its last 
high-end product for the serious researcher. Stand-alone genealogical 
software packages are no longer commercially viable, and the commercial 
market has moved almost entirely to online products sold as part of a 
subscription to large family history websites. This is advantageous for 
the service provider, as it allows them to monetise your family history 
data, but many serious researchers lament the loss of the control, 
feature richness, and personal privacy that a stand-alone product can 
provide.


The plan is to create a high-end product that can be run on a user's own 
computer, with its own integrated database. This allows the user to 
retain full control over their own research data without interference 
from outside commercial organisations. The features to be provided will 
be decided collaboratively by the community, and they will certainly 
include comprehensive mechanisms for recording the sources of each item 
of data within the database, and for documenting the researcher’s 
conclusions about data items and linkages between data items. The 
ability to record reliable sources and conclusions for both data items 
and linkages is, we believe, and a central component of any serious 
genealogy database, a component that is missing from most of the 
commercial online systems that are now available.


As a Wikimedian myself for many years (and currently chair of Wikimedia 
UK) I do see quite a few similarities in approach between the HRE 
project and the approach of the wiki communities. How any connections 
might work would be a matter of discussion, but I can say that the HRE 
community would be more than open to collaboration. Obvious 
possibilities would be for the HRE database to store Wikidata IDs to 
allow unambiguous matching of data items – not only for the people 
within a family tree but also for such things as location data, time 
periods, titles, occupations, relationships, and so on.


Armed with such matches, HRE researchers could leverage the power of 
Wikidata to download or perhaps merely to view a whole range of 
historical information about the primary individuals within the 
database. Similarly, with appropriate agreement from the Wikidata 
community, HRE researchers could have the possibility of uploading to 
Wikidata those portions of their research which are sufficiently 
interesting (“notable”?), along with full details of the sources relied 
upon.


We would clearly need to discuss how to handle data relating to living 
individuals, which might need to be kept confidential, and also to 
develop rules for the reliability of sources to make it clear that users 
can't simply upload personal family trees based on random information 
they have found on the Internet or which have been copied from the 
unreliable family trees that are often found at places such as 
Ancestry.com.


I hope provides useful information for further discussions, either here 
or on wiki.


All the best

Michael
__
[1]  https://historyresearchenvironment.org/
[2]  
https://historyresearchenvironment.org/hre-for-users-of-the-master-genealogist/
[3]  
https://historyresearchenvironment.org/hre-for-historical-and-social-researchers/




Dan Koehl 
30 May 2017 at 12:11 am
Dear Michael, thanks again for your question and request. I hope that 
more members of this list will share their thoughts about this.
I guess no one on the list were so ready for this kind of question, we 
have sort of moved slowly towards a moment when we think we are so 
many that we can start to look into next step, so far we were just 
discussing and discussing.


Your question is interesting relevant, and should have had a much 
better feedback, than those weeks without even an answer.


Lets bring your request a further step, so we can soon move it to the 
meta pages, and discuss openly.


I have to admit, I was not totally sure about your question, and maybe 
this goes for others, would you mind tell us more about your plans 
with this and anything more you want to share. It sounds like a tool, 
connected to Wikidata, which already sounds very good for a Wikimedia 
genealogy tool. you may actually turn up with your request in the 
perfect moment, where technical issues needs to be discussed, we were 
simply not there, but I guess that the group members will just 
consider each