WeRelate talk:Website features

Topics


Helping Out [16 August 2012]

I'm hoping to be able to do at least something to help out. I have some experience in HTML, CSS, and JS. - Jdfoote1 21:20, 15 August 2012 (EDT)

Thanks! I've added you to the list. I'll leave a message here as soon as I get the source code in shape for posting on github. I'm on vacation for the next two weeks; I hope to have it ready by the end of September.--Dallan 16:45, 19 August 2012 (EDT)

Last-Modified HTTP response header not correct? [16 January 2013]

I'm just wondering if there's something odd going on with the Last-Modified headers that are being sent for page requests. For example, when requesting Family:Ralph Denton-Barker and Joan Denton-Barker (1) I get a Last-Modified header of Mon, 14 Jan 2013 11:33:20 GMT (which is actually just the time I made the request), but the actual time the page was last modified was 2012-06-25 14:23:47. Now, there maybe some TZ oddity there, but of course not months and months!  :-) I wouldn't have noticed this, but for the fact that printable-werelate used to be able to use this header to correctly only re-fetch modified pages; it now re-fetches everything!

Has anything changed recently? Or am I imagining that it was ever working?!  ;-) And, does anyone have any ideas on how to make this work?

Sam Wilson ( TalkContribs ) … 06:53, 14 January 2013 (EST)

Hmm... well, it seems to be working again today! Don't know what was going on. — Sam Wilson ( TalkContribs ) … 03:51, 16 January 2013 (EST)

Update? [23 August 2013]

Hi Dallan! How's it going with the opensourcing of the WeRelate engine? Just finding myself back with a tiny amount of time for these sorts of things, and thinking of looking at some stuff... :-) Thanks! — Sam Wilson ( TalkContribs ) … 05:03, 20 March 2013 (EDT)

Sorry - I've started consulting full-time for a company that's in crunch mode until they get a beta launched at the end of May. I'm not able to do anything on WeRelate until then.--Dallan 07:59, 14 April 2013 (EDT)
We will be waiting with bated breath! Best of luck with your current gig. -- Jdfoote1 10:48, 16 April 2013 (EDT)
Do I understand properly that WeRelate is a customization of the MediaWiki platform where the customizations are primarily in those areas where MediaWiki supports customization rather than creation of a code fork leading to a new platform branch? If that is true, then open-sourcing wuold be a matter of documentation rather than code release. --ceyockey 06:20, 17 April 2013 (EDT)
Hooray! Thanks Dallan. The code (all of it?) is now up on Github. I haven't really properly explored it much yet, but first I'm wondering about a few things:
  1. Copyright. I assume that as this is a modification of MediaWiki, it's also GPL. The COPYRIGHT file in the repo, however, says "Files in this project that are not in MediaWiki are Copyright (C) 2010-2013 Foundation for On-Line Genealogy (folg.org)", which is quite true, but I think probably needs a little extra "and released under the GPL".
  2. Where to report issues, on werelate.org or on Github?
  3. What's the plan, viz the development? I rather like the idea of consolidating things into extensions (and a skin), away from modifications to the base Mediawiki stuff. Dallan, your BDFL advice is sought! hehe :-)
Sam Wilson ( TalkContribs ) … 23:15, 7 July 2013 (EDT)
Only the wiki and javascript code are on github at this point. The flex (family tree explorer and gedcom review) and java (indexing) code haven't been posted yet. My goal is to first document how to set up the wiki/javascript code on a local machine, then post the rest of the code and document how to install it as well.
You're right - the copyright and license need to be clarified. The code is released under the GPL, which it must be since it is based upon the MediaWiki software.
I think it would be best to report issues on github. It's better able to track issues than WeRelate.
I've tried to consolidate everything into extensions and a skin. Unfortunately there were a few times when I had to modify the MediaWiki code itself. One of the major goals in the update is to remove the modifications to the MediaWiki code when possible by using hooks that were added to MediaWiki after the extensions were originally written.
BFDL -- I had to look that up. Thanks :-) --Dallan 00:52, 8 July 2013 (EDT)
Thanks for the extra info in the readme. I've been reading the code a bit of the last month or so. :-) My interest is in improving the API access to the data, so I'm focussing on that. Although, before anything real of course it's a matter of bringing things up to the latest Mediawiki. Anyway, I've not got much concrete to share yet, all I wanted to mention was that Github have a 'organisations' thing, which might be a better match for https://github.com/werelate (i.e. not a 'user'). :-) Thanks again for your work on all this. — Sam Wilson ( TalkContribs ) … 19:39, 22 August 2013 (EDT)

Graph DB [15 September 2013]

Have any of you used a graph DB (e.g., http://www.neo4j.org/)? They seem like they might be an interesting way of storing relationship data, especially if we want to create queries that traverse the graph (e.g., "How is Person X related to Person Y"). -- Jdfoote1 12:46, 12 July 2013 (EDT)

Interesting stuff, I agree. I've not really looked into it deeply. Mainly because actually I'm finding that traversing the tree isn't really the most expensive part of what I'm doing with this stuff — at most, I'm going a dozen steps from some starting point, and so the relational model is quite fine. Of course, for big visualisations etc. things would probably grind to a halt, but they're less common. Certainly, for the usual use cases of browsing a family section and not much more, there's really only a handful of DB queries... :-) Still, keep us posted about anything you come up with! — Sam Wilson ( TalkContribs ) … 07:03, 15 September 2013 (EDT)

Local Build [25 August 2013]

Is the code ready to be run locally? I have been trying unsuccessfully to get it to run today. I'm sure I probably have some environment variables wrong, or haven't installed something I need, etc. I don't have much expertise in running the web stack, so I'd probably need some hand-holding (maybe through our newly-discovered IRC channel?), if anyone would have time. -- Jdfoote1 15:18, 24 August 2013 (EDT)


I've rejigged it a bit to be able to install locally; see this branch: https://github.com/samwilson/werelate_wiki/tree/local-install

Shifted environment variable definition into a new .htaccess, and changed LocalSettings.php a bit to support these (not use memcaching if it's set to false, etc.). I've also rebased on top of the main mediawiki tree, so that all authorship is correctly retained etc. and mainly so it's easier to find what's changed between the mainline MW and the WR fork.

I'm on IRC most days. Would be happy to help if I can. :-) See you there!

Sam Wilson ( TalkContribs ) … 21:17, 24 August 2013 (EDT)


WikiMedia Conversation [15 September 2013]

I know that some of you have already been involved, but there is an ongoing (albeit slowly) conversation here about making WeRelate a WikiMedia project. I made a few comments, and want to make sure I didn't misrepresent the goals here (especially Dallan's situation). FWIW, I think it would be great to be part of WikiMedia. -- Jdfoote1 15:42, 14 September 2013 (EDT)

I hadn't checked that page for ages; thanks for the pointer. :-) It's slow, yes, but that's better than nothing! I also think it'd be great to have a genealogical wiki as part of the WMF family; not sure it's all that likely though. :-( I've sometimes wondered if Wikiversity would accept family histories — probably not en masse, but it does accept original research, and it might be an avenue to explore...
On software matters, I've been playing a bit with the WeRelate codebase: both modifying the existing, and playing with some ideas I've had in the WeRelate-as-set-of-Extensions space. At the moment, I'm focussing on producing printable books, and in the process synching WR data into a local wiki (e.g.). There's lots missing from my work so far! I'm not even sure what the right direction is... I've been playing with SemanticMediaWiki as well, which really does hold some promise.
One thing I'd love to get cranking is the idea that I could run my own private family wiki (with living people) and have it tie in to the broader WeRelate data... If only there were more hours in the day (or fewer spent at work)!
Sam Wilson ( TalkContribs ) … 06:45, 15 September 2013 (EDT)
Keep us posted about what you are working on. I am a very amateur programmer, but I'd love to help out where it would make sense (I have some limited frontend (JS/HTML) experience, as well as Python). -- Jdfoote1 19:18, 15 September 2013 (EDT)

Full WeRelate source code and installation scripts available on github [16 October 2013]

The full WeRelate source code and installation scripts are now available on github. The source code has actually been on github for awhile now, but I've recently added the install scripts project to make it easier to install, and I've used the new install scripts to set up the sandbox. I've tried to simplify the installation/configuration process as much as I could, though there is still room for some improvement. Feel free to install it and play around with it. If you run into any difficulties, please post an issue on github. Pull requests are welcome!--Dallan 01:40, 15 October 2013 (UTC)

Someday I'd like to migrate WeRelate to Semantic MediaWiki or Wikibase. I haven't had any experience with either of those two projects; I'd love to hear others' experiences. Please create issues and add comments on github.
Also, WeRelate is currently running on a very old version of MediaWiki. I'd like to start migrating WeRelate to the latest version of MediaWiki very soon. Ideally I think we should create a new branch from the MediaWiki git repository. But I'm not a git expert, and since the existing branch is not based upon the MediaWiki git repo, I'm not sure whether its kosher to simply add the MediaWiki git repo as an origin and create the new branch from there. I'd really like to hear advice from someone with more "git fu" than I have. I've created an issue about this on github.--Dallan 01:49, 15 October 2013 (UTC)
Thank you for working on this Dallan! It's great news. I've been working a little bit with the wiki codebase that you uploaded a few weeks ago. I'd love to hear your thoughts about the end goal for the structure of things, because I rather went round in circles trying to figure out where to start! :-) Do you see WeRelate as being a stand-alone application based on MediaWiki (i.e. with continued modifications to the core) or as (for example) a collection of extensions that can be added to a MediaWiki installation?
In the vein of the latter, I've been tinkering with a set of extensions: Core, Sync, Book, and Treebranch. Basically, I was looking for a way to clone (Sync) my WR data (Core) into a local wiki and combine it with private information, and then produce a printable book (Book) from sets (Treebranches) of the resulting data. :-) I was going to start looking at an editing extension too, but haven't really had time lately... too many family documents to scan at the mo'!
As far as SMW goes, I've been using it for the last few years, and think it's pretty great. It could certainly do a great deal of what WR does without too much hassle, and the extra stuff could be built on in standard SWM ways (e.g. a Result Format for browsable graphical trees). I guess the part of that possible future that I don't understand very well is how the migration from one data store to another would be handled. All history would have to be kept, that's the main trickiness I think. At the moment, we browse history in terms of text modifications to XML constructs; certainly, the easiest way to switch to an alternative (e.g. SMW) way of storing data would be to just transform the current XML into semantic templates, and just accept that every page would have a massive and hard-to-diff-against change in its history. Hmm... not sure that's great. :-) I'm not sure that there's anything too much the matter with the current XML-for-storage approach, anyway; the extensions I've built above are all built with the idea that they can just be pointed at a standard MW installation that contains WR data and will work. No data should be stored outside of pages (of course, cache data is, but that can be rebuilt).
Anyway, I can ramble on for hours about this I'm sure! Really I'm just wondering what the vision is, and where I can help. :-) Thanks!
Sam Wilson ( TalkContribs ) … 08:52, 15 October 2013 (UTC)
Sam, I'll have to take a look at what you've done - looks like some terrific ideas!
I'd really prefer WeRelate to be a set of extensions. Core modifications were made only when I needed hooks that core (at least at that time) didn't provide. Every core modification is an upgrade headache. There are around two or three dozen places where core code has been modified, and I tried to minimize them as best I could. But I'm sure I could have done better, and it's likely that the latest version of MediaWiki has more hooks that remove the need for many of the core changes I made.
Ultimately I think the best role for WeRelate in the genealogy ecosystem is the repository for well-sourced genealogy. Syncing with private databases is key to that -- we need a good syncing api. We also need to do a lot better on sources -- maybe modify our model to be more source-centric / evidence-based.
Here's something I've been thinking about recently: what if we associated "votes" with every assertion on a Person page? People could vote each assertion up or down, just like they do on StackOverflow or Quora. When you upload your gedcom or sync data from your private database, you never replace existing data with your own data, you simply vote up matching assertions or add new ones. In this way, syncing is non-destructive, so it could even be done in the background with minimal or no user intervention. WeRelate would track which users have voted each assertion up or down. User votes could be tracked in the XML right alongside the rest of the data. Assertions that receive a lot of down-votes in comparison to the number of up-votes would be hidden by default. The name, birth, and death assertions with the highest number of votes would show in the infobox at the top of the page.--Dallan 20:09, 16 October 2013 (UTC)