WeRelate talk:Watercooler


WeRelate Watercooler 2017 [15 March 2017]

This page is for discussing anything you want to discuss, unless it relates only to a specific page. If it does, then post your comment on the Talk page associated with that specific page or on the WeRelate Support page.

To learn about using this Watercooler page or to ask questions about using it, go to Help:Watercooler.

If you don't want to leave comments on this page, you can email them to dallan@WeRelate.org.

Are you a new user? Have a question about how to use WeRelate? Post it to WeRelate talk:Support.

Old topics have been archived: 2006 | 2007 | 2008 | 2009 | 2010 | 2011 | 2012 | 2013 | 2014 | 2015 | 2016

WeRelate Page Growth Statistics [13 July 2017]

For anyone who is interested, WeRelate has grown from 2,750,000 Person pages (July 2016) to over 2,824,000 Person pages (July 2017).

Image:WeRelate Stats.png

During this time, a significant (and ongoing) effort to comply with the "no living persons" policy and to improve data quality overall has resulted in thousands of pages being deleted, merged or updated.

A couple of rough measures of data quality improvement are:

The percentage of Person pages with first name Unknown has been reduced from 2.02% (July 2016) to 1.70% (July 2017).
Image:WeRelate First Name Unknown.png
The percentage of Person pages with no birth country has been reduced from 36.99% (Dec 2016) to 35.68% (July 2017).
Image:WeRelate No Birth Country.png

--DataAnalyst 03:00, 14 July 2017 (UTC)

Based on your statistic above, I'm guessing you and cos1776 are working in opposite directions regarding the use of "Unknown" as a first name, e.g., Person:Unknown Triggs (1), and Person talk:Unknown Seaver (18). --Jrich 16:38, 12 February 2017 (UTC)
I don't think so. As far as I am aware, the reduction in the name Unknown is due to finding names for pages. At least, that is what I have been doing.--DataAnalyst 22:09, 12 February 2017 (UTC)
He is converting many pages to have given name Unknown, so increasing the number. Your choice of it as a statistic to measure and report on suggests you don't believe that is a good thing, that it is a measure of bad quality. The pages are, in the two cases cited, and many other, names that were never given, so not precisely unknown. To truly reflect pages where the given name is unknown, meaning under-researched, as opposed to never-knowable, the latter case should be given a different value or else they will always remain "Unknown", inflating the count. There are various practices that have been employed on this website for this special case, I believe Unknown is not appropriate. --Jrich 22:51, 12 February 2017 (UTC)
Metrics need not be perfect to be useful - particular when used to show change over time or some other variable.
I would certainly like to know if there's a different custom for a first name that is unknown at the moment versus something that is asserted to never be knowable. I treat both as "Unknown" at present, and suspect that's what folks have done for years. I suppose the key question would be whether there's a generally accepted best practice for such given names in GEDCOM files - if so - we would presumably want to follow that.
More generally - I looked for some other common forms for an unknown first name (typically in the case of stillbirth or infant death). Searching in the first name field: "Child" - 673, "Female" - 641, "Male" - "580", "Infant" - 1302, "Baby" - 537, "Boy" - 266, "Girl" - 224, "Stillborn" - 155, and "Unknown" - 30,628. So there may be another 1/10th of a percent that neither measure accounted for - but I assume the defect was approximately the same in both numbers so the delta is still meaningful. --jrm03063 18:28, 13 February 2017 (UTC)
Daughter - 846; Son - 837. "so the delta is still meaningful": some of the alternate forms are being changed to unknown. So while one set of cleaners is reducing unknowns, another cleaner is add unknowns, so the delta understates how much cleanup was done. Besides the question this raises about the validity of the statistics, the use of alternate forms has been intentional on many pages specifically to distinguish from unknown, and changing it to unknown loses that information. --Jrich 19:00, 13 February 2017 (UTC)
I wasn't aware that other ambiguous forms were being substituted in preference to "Unknown". My memory is that we never distinguished between unknown at present and unknowable - and that the proper form in either case was simply "Unknown". But no matter - the question remains whether there's an accepted GEDCOM best practice on this. Also, does historical guidance here at WR suggest different variants of unknown? --jrm03063 19:27, 13 February 2017 (UTC)
Keep going... we also still have roughly
  • Dochter = 36
  • Zoon = 39
  • Levenloos = 152
  • Levenloze = 60
  • Doodgeboren kind = 14
  • Wife = now 61, but was abt 150 that have either been sourced with a name or changed to Unknown
  • Fru = 5
  • Frau = 5
  • Hustru = 2
  • Vrouw = 2
  • Miss = now abt 380, but was 432 that have either been sourced with a name or changed to Unknown
  • Husband = 62
  • Man = 5
  • Mann = abt 20 where it means "husband"
  • Første Mann = 2 (first husband)
  • Unk = now 0, but was abt 200 that have either been sourced with a name or changed to Unknown
  • FNU = now 0, but was 124 that have either been sourced with a name or changed to Unknown
  • GNU = 3
  • Unnamed or (Unnamed) = abt 225
  • Naamloos = 4
  • Not known = abt 50
  • Not used = 2
  • Not named = 9
  • NN or N.N. = abt 1249 (Nomen Nescio)
  • Anonyme = 19
  • Inconnu = 1
  • Unbekannt = 6
  • Onbekend = 7
  • Don't know = 2
  • Young = abt 25 that are suspect
  • and on it goes ...
There is no standard convention for this. Entry is based on user preference. Yes, I have cleaned a lot of this up and been mostly standardizing page titles to "Unknown xxx" when the given name is unknown for any reason as opposed to one of the words in the lists above. That is what our program defaults to when the field is left blank and the logical place to look for Unknowns in our wiki page lists. Most of these pages came in with old GEDCOMs, have zero sources, and haven't been touched since 2007-2009. For our site, the "quality" of a page is not only measured by the amount and type of genealogical proof attached to the data, but also by the ability of that data to function with our program and with other programs (if it leaves). Improving both of these is important.
Entering the simple word "Unknown" in the Given name field, as was pointed out, has been acceptable here since the beginning. Now, if you want to talk about that convention, I'd be glad to, because I would also like to see it changed. However, not in the way that is being discussed. In a nutshell, name fields are for names only! We should not be entering any placeholder words or made up names into any Given name or Surname fields for which we don't have a sourced name - not "Unknown" or "Unnamed" or "Stillborn Daughter" or "Levenloos kind" or anything else. When we do not know a particular name part, the corresponding field should remain blank. So, following this convention, the correct way to enter children with no given name, for any reason, is to enter just the complete surname they inherited from their parents in the Surname field and to leave the Given name field blank. Our software handles that just fine, as do other programs, and any confusion about what is being implied or in a different language, etc. is eliminated. There are other data fields on the page better suited to clarification when it is needed. --cos1776 01:26, 14 February 2017 (UTC)
Things like wife and husband should translate to unknown. Presumably if they lived long enough to marry, they had a name, and the poster didn't know it. This would seem to be exactly the definition of unknown. But that is different than the situation where a name was not believed to have been given, as in Unknown Seaver, female, formerly (female) Seaver who was born in 1865 with no name listed in the birth record and not listed with her family in the immediately following census in 1870 and had no gravestone in the cemetery where other family members are found on Find A Grave. Maybe there is no desire to distinguish between the two cases the result in having no name to post, but I am pretty sure distinguishing exactly that was the intent of the poster in using "(female)" as opposed to the unknown he uses on other pages.
Of course, there is no convention, and as will always be the case when there is no convention, that means everybody does something different. So the first step is to decide if this is significant, then, if it is, how to distinguish it from simply unknown. The fact that dataAnalyst was using Unknown as negatively correlated to data quality suggests it is significant. Maybe because users that are likely to be unaware of this rule can upload GEDCOMs, or because language variants provide too much variability, it is believed pointless to try. That is for the group to decide. Distinguishing data values don't have to be in the name field but that of course has the advantage of getting propagated to the infoboxes and erased automatically by the name if it ever gets discovered that a name was given. But there are other ways, one of them being the various title fields, or add a new fact type, or adding some template to the Narrative (a la nomerge}.
This is a relatively trivial matter, but for that reason, probably a good chance for the Overview Committee to start developing a process for developing such conventions and notifying the user community (is there one page everybody should be watching?) Date conventions are fairly detailed, but there are lots of other conventions that could use some serious discussion, like Married Name, like handling Intentions, like what data is best posted on the Person page and what data is best posted to the Family page. Wikipedia, as an example of a more mature wiki, has its usability is greatly enhanced by the fact that most town pages have similar outlines, most kings are presented in a similar style, etc. I believe similar attempts at standardization are needed here. --Jrich 02:35, 14 February 2017 (UTC)
Well, this is a case where a GEDCOM best practices document would help (for example, I'm pretty sure the GEDCOM spec is silent on the question of whether dates before 1000 should have a leading zero - and no one would want to write a GEDCOM interpreter that required a leading zero there - but a best practices document would give guidance on which form was preferred). So if GEDCOM proper doesn't dictate what Unknown ought to look like (I don't think so at least - unless their idea is that it should be empty). We should first make sure that guidance isn't lurking somewhere in that spec. If GEDCOM leaves specification of unknown up to the application/user - then we should probably look at conventions used by the more common Genealogy systems out there. Both web sites and desktop applications. This seems like a common enough situation that some practice will be found to be a little more prevalent than the others - and we should therefore follow whatever practice seems most common. Do GEDCOMs in the care of LDS follow a practice? If so, then, etc.... --jrm03063 18:54, 14 February 2017 (UTC)

I applaud the efforts of people working in the Data Quality Improvement project. This is the single best chance for WeRelate to make a difference in my opinion. Every time I investigate other sites, spoken highly of by various people, I continue to find inferior quality, and decide to stay right here at WeRelate. This particular project is the one that I think most adds value to WeRelate, and hope that at some time, the percentage of quality data might make this the site the one primary place where people will go to share new discoveries for review, to correct long-standing myths by providing evidence, and where we can build a culture that says what you know is not as important as how you know it. --Jrich 03:25, 21 December 2016 (UTC)
Thanks. I agree that quality has become somewhat of a focus of the collaboration efforts at WeRelate, and I'd like to see us fit that niche of where you go to find trustworthy data. We're still a long way from there for some of the old GEDCOM data, but where there is a high degree of interest in data (e.g., early New England and New Netherlands), I think we've got some pretty good quality. And where we're fixing up the old GEDCOMs, I know that we are ending up with parts of trees that are better researched than anywhere else available online.--DataAnalyst 13:11, 21 December 2016 (UTC)

Excellent ! Thx, Ron woepwoep 08:45, 21 December 2016 (UTC)

I also appreciate that there are folks willing to clean up whatever needs it. But when it comes to 'Unknown' I wonder about that as I use it a lot! And on occasion I've used terms such as Son or Daughter. Perhaps I've studied pre-1850 census records and know they had a son in the prior time but have not discovered the name of the child. At least Son or Daughter with est year period gives some info that I wouldn't want to lose by just saying Unknown. And to remove a page for a wife where the only name is Ann Unknown would really be destructive. Please tell me you are not removing that type of unknown page. On second thought that could be acceptable IF there were no children AND IF her first name is given on her husband's page. --janiejac 03:42, 13 March 2017 (UTC)

An aside: My computer says it is only 12 March 2017; 11:49PM --janiejac 03:50, 13 March 2017 (UTC)
I believe the UNKNOWN and multiple related usages of unknown names are an open discussion topic at this point. I think it is a maintenance issue which needs to be addressed because it strays from the WR standard. I'm not sure the use of "Unknown" is fully appropriate for all cases, but the list of unknown names above certainly shows that various usages need to be pared down to a more acceptable use standard.
Please consult this article about your off-topic aside relating to the use of UTC. --BobC 13:42, 13 March 2017 (UTC)
May I request that you move this discussion to a separate page, and offer a draft policy? I still do a lot of cleanup and would appreciate better guidance. --jrm03063 15:31, 13 March 2017 (UTC)


how to find template [24 December 2016]

I found a GEDCOM with what appears to be no sources, but I didn't know where/how to find a template to mark it 'needs sources'. Even if you tell me where to find it, I may not remember it. (Memory NOT improving with age!) So is there a way to easily locate this kind of thing? Where it is hiding? Maybe we need a link at the top of pages to an index of sorts. That might help lots of folks. --janiejac 02:20, 22 December 2016 (UTC)

Hi, Janie. I think the template you want is Template:Sources needed. You can find any template by searching the Template Namespace (Select Search from the top menu, then All, then Template). I entered "Sources" in the title and found the template, although I did have to look a bit because there are a few that are similar. Take your pick.
I agree about making it easier to find these things. I'm hoping that this is one of the things that will come out of Overview Committee work over the next year.--DataAnalyst 02:43, 22 December 2016 (UTC)
I believe {{Sources needed 1}} is better as it includes a message that encourages referencing contemporary documents and not just copying from other unsourced items (i.e., passing the buck). --Jrich 03:22, 22 December 2016 (UTC)

If there's one thing I have used more than any other this year on WeRelate, it's #redirect. It's absolutely vital in working on Places, but it would probably be just as useful for bringing together Templates and Sources that really ought to be together. Merry Christmas! --Goldenoldie 16:48, 24 December 2016 (UTC)

Seasons greetings from the Overview Committee [24 December 2016]

On behalf of the Overview Committee:

Seasons Greetings! The Overview Committee is back in action after a few bumps this year. Getting ourselves organized is taking a while, but in the meantime, 2 members (Cos1776 and DataAnalyst) have initiated a refresh of WeRelate Help.

We've put a considerable amount of thought into how to organize Help, but we need to do some more work before it is ready to share (hopefully by the end of January). In the meantime, I have requested further community discussion on a couple of date conventions so that they can be included in Help pages (and hopefully even automated). Bear with us. While this is a slow time for one of us (off work for 2 weeks), it is a busy time for the other (lots of Christmas activity and travel).

Best wishes for 2017 from the Overview Committee!--DataAnalyst 14:33, 24 December 2016 (UTC)

Ancestral File Number - perhaps not completely useless [13 April 2017]

Until this year, I had been preserving AFN numbers, even though I hadn't seen a use for them. I had changed that practice, but another contributor suggested that they have some worth. Digging in, I found that I was able to create the AFN template that turned the bare number into a (potentially) useful link. Examples of use include Person:Edward Gilman (1) and Person:Jacob Gates (17). If you're cleaning up a page, it's nice to at least use the template to make sure that a retained AFN actually corresponds to that person (I've found several incorrect AFNs). Valid AFNs seem to have a seven character syntax of the form "llll-ll". --jrm03063 21:28, 1 March 2017 (UTC)

Nice addition. Will you be adding usage and example to the Template page?--khaentlahn 21:39, 1 March 2017 (UTC)

Should...but won't prevent anyone else from doing so either... --jrm03063 22:02, 1 March 2017 (UTC)
As I've previously noted, I don't have a strong opinion on AFN. I formerly thought them utterly useless and dropped them when I had a Wikidata reference number to substitute. Another member of the community offered however, that they should be retained for the sake of folks familiar with LDS materials. That's ok by me, and seemed even more reasonable when I found that I could wrap them in a template, that turned them into a link to corresponding LDS legacy content.
Since then however, I've had a couple of such facts I wrapped deleted for reasons that seem arbitrary (not just the template, but the entire fact).
Honestly, I don't care a lot on this, but I want the community to weigh in. I don't want to waste time on them if they're worthless - but I'm not sure how worth is defined here. If the AFN maps to a corresponding name in the LDS world - that seems like it should be retained.  ??? --jrm03063 15:27, 13 March 2017 (UTC)
HEY - SOME HELP HERE? I'm trying to do "the right thing" regarding AFNs - but the community hasn't articulated what that might be. To my mind, that means keeping them when they point somewhere. One other person, is of some other mind. I'm only keeping them because other members of the community have expressed interest in their retention.
To look at pages where we have an AFN template, see this page
Unless something like a quorum chimes in - I'm going back to my old practice of blowing them away whenever I add anything substantive to a page where they exist. --jrm03063 17:43, 12 April 2017 (UTC)
The way AFNs work seems to have changed since most of the AFN references were posted, which may limit what can be done. But that said, given the way they work now, the template creates a useless citation. On Person:Roger Strange (1), the template gives you a search yielding "247 results for Ancestral File Number: 83TZ-QT". So the reader has no idea which of the 247 AFNs provided the data for this page. Undoubtedly the original poster had one AFN in mind, probably the first result listed. But wouldn't it be better then to unambiguously specify one item by using the URL that takes you right to it? Again that is assuming we have correctly identified which of the 247 items the poster meant.
That is all prior to considering whether it is worthwhile to even cite AFNs. Which has been hashed out before, but proper genealogical practices says if no sources are specified, then no, if yes, then it is better to inspect the sources and cite them, making the AFN superfluous.
I think it is wrong to delete an AFN before providing alternate sources for the information. There have been pages where it is necessary to locate the AFN in order to figure out what the intent of the poster was, i.e., the WeRelate page has little or no identifying information on it, and you need to find who the AFN says the person is related to, etc. But that is an immature page, and I think on a mature page, there should be no need for an AFN citation. --Jrich 18:34, 12 April 2017 (UTC)
I'm one of those WR users that would prefer keeping the existing references to the AFN. For the most part I look at the AFN as a "Finding Aid" for the individual referenced rather than a "Source" in itself, so why go to the extra work of deleting a finding aid for a person that may provide other users the ability to reference legitimate sources identified by using the AFN? So what if it points to 247 results. That tells me there may be 247 potential sources to add to the individual's record. The Wikidata number, of which you are taking tremendous time and effort in adding to WR person pages, in and of itself is not a source either, but it points to a compiled record of sources for that individual referenced in other places.
I say leave them be where they are unless they point to nothing. --BobC 19:20, 12 April 2017 (UTC)
The problem with this is the AFN is not a unique number identifying all instances of this person. For example 2CT3-857? only brings back 1 instance of Roger Strange as opposed to the above. I also think finding aids should be listed on various portals, but not listed on individual pages. If every finding aid was to be listed, one could devise a query of all worldconnect databases that mentions an a person, and call it a finding aid. They tend to be of as at least as reliable as AFNs. Virtually everybody is in AFN, so why do we need to put a finding aid on all the page? The value people can bring to WeRelate is to process this type of data, turning it into information by culling it down, vetting it, and presenting it with credible evidence to support it. Citing AFNs is simply passing all that work onto the reader, meaning they may as well skip WeRelate and simply go search familysearch.org. --Jrich 20:39, 12 April 2017 (UTC)
Here's my $0.02. If there are no other sources on the page, I support leaving AFNs alone temporarily. I am guilty of removing them in the past, because of their lack of uniqueness, but I will leave them alone going forward if others wish to retain the ability to use them as a potential path to true sources. I don't think the template adds much in this case, so I will probably not spend time adding it. Once sources are added, AFNs become no more useful than other online tree links, so I would support removing them at that point. --cos1776 20:17, 12 April 2017 (UTC)
I've seen lots of strings represented as AFNs. Not all of them are - or at least - they're not all AFNs defined by LDS. I'm for wrapping an AFN in a template reference to show that I've verified that the string actually goes to a corresponding LDS page (and to make it easy for someone following me to see what I saw). When AFN strings don't resolve to anything - I definitely throw them away. The template could also be useful in letting us systematically find our way back to pages that have limited documentation (if that's what we're going to call an AFN situation).
If we're going to have a rule that AFNs can go away, when a page is more substantially sourced (or the person identified - which seems the real purpose of AFNs), it would be helpful to at least define a few examples of things that rate as "more substantial"? Presumably, a Wikidata identifier is a better identifier than an AFN, so perhaps we would drop it then. A cite to Cawley or History of Parliament is probably better. Even Find A Grave if an image of a contemporary memorial is provided. --jrm03063 16:47, 13 April 2017 (UTC)

I didn't know it was good practice to cite rather than point, so i am glad i am doing the right thing.

I don't think one is exclusive of the other - depending on what you're working with. --jrm03063 16:47, 13 April 2017 (UTC)

Some time ago i asked my premier source, www.geldersarchief.nl, if they have something like a permanent link to each of their records. They said yes we do - more or less - and then told me how to retrieve it. Still some of the records are duplicate information registered in different records for some reason.

So i like to copy the info from one or more of those duplicate records and referring to the source that www.geldersarchief.nl is also referring to. The different info is for example the many ways Anthony was written (Antoni, Antonij, Antonius, Toone, etc).

Thx Ron woepwoep 07:08, 13 April 2017 (UTC)

Stranger Than Normal Pipe Redirect [12 March 2017]

To whomever is in charge of these types of situations, I had a very strange pipe redirection happen. I attempted to enter a cemetery name (Mount Pleasant Cemetery, Brilliant, Marion, Alabama, United States -- which at the time did not exist) into the Burial field of a Person page. I refreshed the Person page and went to create the cemetery. Imagine my surprise when I was met with the attempted creation of Mount Pleasant Cemetery, Brilliant, Marion, Fort Rucker, Dale, Alabama, United States. I went back to the Person page to remove the pipe and test whether it was possibly user error that caused the fubar. No such luck. The pipe was created automatically by the system.--khaentlahn 03:17, 13 March 2017 (UTC)

FREE access this week to Irish records [16 March 2017]

In celebration of St. Patrick's Day, Ancestry.com has free access to their Irish records until 11:59 p.m. EST on 19 Mar 2017.
Happy Hunting, --cos1776 21:09, 13 March 2017 (UTC)

Information about Edward Thornton born 1644 Richmond Co Va died Accomack Co VA 1703

married Patience unknown family/children: Yes Go to site of Eastern Shore Public Library : www.ESPL.org, then select genealogy, then Miles Files, then Surnames, click on Thornton and scroll down results to Edward. Interestingly, none of your early family information is recorded here but takes it forward from Edward to my paternal grandmother Beatrice Louise Thornton, who married John Walter Young, parents of 4 sons (to include my father Norris John Young). Enjoy capturing this lost information for the We Relate site's benefit.

Leigh Chase, Sanford FL--LeighChase 22:23, 15 March 2017 (UTC)

Follow up - comment copied over to Edward Thornton's talk page, Person talk:Edward Thornton (1). --cos1776 18:17, 16 March 2017 (UTC)

uploaded GEDCOM taking a long time [18 March 2017]

I must have been wrong when I assumed I had rights to get my GEDCOM accepted w/o admin review. It was always accepted so quickly before but today it is taking a long time. I uploaded it at 2:20 this afternoon and still is not accepted so that I can review it. I realize we're short handed or maybe my status has changed??? --janiejac 22:05, 16 March 2017 (UTC)

It looks like it may be stuck on Waiting for analysis. Normally I can review GEDCOMs just fine, but it's currently in a state where I can't do anything. It may need to be re-uploaded, but I'm really not sure.--khaentlahn 22:11, 16 March 2017 (UTC)
Janiejac - your admin rights have not changed. I put a request in to Dallan to take a look at that file, so hopefully we'll have an answer soon. He is still the go-to person for files that are stuck in the automated part of the process. In the meantime, can you re-create your GEDCOM under a new name name and try uploading again. If the 2nd version processes normally, please proceed with that one, and leave the 1st version as is. If the 2nd version gets stuck as well, please contact either Dallan or me and we'll go from there. Thanks, --cos1776 11:46, 17 March 2017 (UTC)
The system won't let me upload a renamed GEDCOM. I get this msg:

You have a GEDCOM already in process
Before importing a new GEDCOM you need to wait for your earlier GEDCOM to finish importing
I'll copy this exchange to Dallan's talk page. --janiejac 23:17, 17 March 2017 (UTC)

Follow up - Issue resolved earlier today. Server needed a re-boot. --cos1776 01:00, 19 March 2017 (UTC)

FREE access until Apr 25th to probate records [20 April 2017]

fyi - AmericanAncestors.org is granting free access to their probate databases Apr 18-25 to those who register as a guest (no further obligation). Happy Hunting! --cos1776 11:53, 20 April 2017 (UTC)

I believe some of the probate records are free all the time because of various agreements that were made while getting access to the records, either with the government agency or the Mormon church who is a partner. Since I am a member of americanancestors, it is not obvious to me which records are restricted, so I cannot give any insight into which areas are particularly benefited by this special promotion. I know some counties in Massachusetts are always free.
Since I feel probates are one of the best tools of genealogical research, not just the wills but receipts and distributions, I will also add that many probate records are always free at familysearch.org. Go to catalog search, enter the place name and subject probate. Find the entries whose author is a government agency and browse the list of films. If the icon is a solid film reel it is viewable online by clicking the icon. If the icon is an empty film reel, you can still order it to be viewed at your local Family History Center. None of this requires any affiliation with the church, though ordering films will require creating a free account and a small rental fee per film.
The viewable probate records are rarely indexed so you have to search the old fashioned way. Use the film of the index to get a case number, then go to the film of the dockets and find where all the documents for that case are recorded. Then click on the film for each record volume and jump to the indicated page. Some counties do things slightly differently. If your county has files, you can probably find all the original documents in one place, instead of jumping through several films reading copies as recorded by the clerk. --Jrich 13:40, 20 April 2017 (UTC)
I will also add that typing a transcript or abstract of a will from a film is a big service to the entire genealogy community, not just WeRelate, as it makes something that is non-searchable into something that search engines can process. So if you read a will and it doesn't help you, it is still worthwhile to post the information on the appropriate person page. Include the link and future readers of the page can add their insights into the often challenging task of interpreting handwritten documents. --Jrich 13:46, 20 April 2017 (UTC)

Problem with display of Duplicates page [27 April 2017]

There seems to be a problem with the display of the Duplicates page ( http://www.werelate.org/duplicates/families.html ) It starts : "I+and+Morning+Unknown+%281%29">", and is very truncated. Can this be fixed? Thanks, --GayelKnott 18:24, 27 April 2017 (UTC)

I have made some tweaks, but since that report only gets updated every 24 hours (I think that's right), I am not certain sure if my tweaks have improved the situation yet. Let's check back on it tomorrow. In the meantime, it is ok to work on the pages you can access. That shouldn't adversely affect anything. Thank you for staying on top of the duplicate report. Your help is much appreciated. --cos1776 21:20, 27 April 2017 (UTC)
Excellent tweaks! Thanks, Gayel--GayelKnott 00:16, 28 April 2017 (UTC)

Wikidata - in case you're wondering... [7 July 2017]

By now, I expect that most active users have seen me placing references to a Wikidata template on Person pages associated with people found in Wikipedia. From time to time I have offered partial explanations of what I had in mind - but nothing systematic. I would usually indicate that my idea involved some level of software supported analysis.

I was reluctant to go on too much about this previously - because I didn't have a handle on all the pieces I expected to need.

I've now reached a point where I've established a subset of content and created an initial support program. People interested in seeing a more complete explanation of what I'm doing can find it here. --jrm03063 22:03, 9 May 2017 (UTC)

Thanks for the explanation. --GayelKnott 00:26, 11 May 2017 (UTC)
Highly interesting blog post on "Library Metadata Techniques and Trends", by Thom Hickey. As a practical matter, we have been using English Wikipedia as a subject registration service for WeRelate. When we source a page from the English Wikipedia, for the sake of a Person: page, we're making a strong assertion about EXACTLY who we mean by the person for that page. This arose naturally from the rationale for the original Wikipedia Person project - trying to de-duplicate and make sense out of large spaces of older era genealogy that were uploaded with almost no practical source support. The blog entry offers an explanation of the relationship between Virtual International Authority File (VIAF) and English Wikipedia - and explains their shift from English Language Wikipedia to Wikidata. This explanation is very much what I might have hoped to offer this community, substituting WeRelate for VIAF.
I see an important opportunity here for the longer-term relevance of WeRelate, in the WikiMedia information universe. The various language versions of Wikipedia have created many thousands of useful biography pages. Wikidata has appropriate properties and is well suited to objectively representing the genealogical connections among those pages. However - efforts to obtain the genealogy information from the various language Wikipedia pages have been haphazard. A lot of information has been obtained to be sure - particularly for pages where templates nail down parents, siblings, children, partners, etc. - but vast numbers of biography pages are not equipped with that organization. The effort to bring in English Wikipedia to WeRelate Person: pages - for the pages so included - gets past that problem in the MediaWiki information space.
Using WeRelate Person: pages tagged with Wikidata identifiers - I have been able to determine and create 4000 new genealogy claims in Wikidata. Another 5000+ claims are pending a more efficient process of uploading them to Wikidata. As more WeRelate Person pages are tagged with Wikidata IDs - we will be able to easily recognize missing genealogy claims from the Wikidata/WikiMedia and generate dumps for automatic upload to Wikidata.
Without even becoming a MediaWiki project - WeRelate could yet become important to genealogy in the MediaWiki space. Perhaps - we need not choose between a slow fade to irrelevance or surrender to the WikiMedia collective??? :) ? --jrm03063 18:24, 7 July 2017 (UTC)

Crowdsourcing Challenge Update [1 June 2017]

Since the WeRelate Crowdsourcing Challenge page is being followed by only about a dozen users and has gone through some changes over the past year, it was suggested to me that I should promote the page here to a wider audience and encourage other users to participate.

Last month's Challenge highlighted historic Memorial Day personalities, General John A. Logan, who proclaimed the first Memorial Day observance in 1868 (then known as Decoration Day), and Ms. Moina Michael, who conceived the idea of wearing red poppies on Memorial day in honor of those who died serving the nation during war. WeRelate users Khaentlahn and Btomp made the most additions and changes to the two pages and were awarded Challenge Badges.

This month's Challenge focuses on two patriots who were instrumental in creating and celebrating the United States flag, Philadelphia seamstress Betsy Ross, who as legend has it sewed the first stars and stripes flag 240 years ago this month, and Wisconsin dentist Bernard Cigrand, who is credited with being the "Father of Flag Day," which celebrated on June 14th every year.

All users, new and experienced, are invited to participate in the Challenge. The Challenge is intended to be a fun, educational and rewarding way for WeRelate users to strengthen their genealogy research skills, enhance wiki-page proficiency, work toward data-entry mastery, and provide practical experience in validating and substantiating factual events with supporting sources in a friendly, collaborative, crowdsourcing environment. Highlighted pages now change monthly. (You can view some of the past subjects and winners the contest/challenge has highlighted over the past five years.)

Come join the challenge. --BobC 13:56, 1 June 2017 (UTC)

There seems to be a computer problem with the Duplicate Families Report [17 June 2017]

For over a week, the report appears to be truncated, cut off at "Multiple Parents R". Among other things, this means the multiple spouses on the same page are not being reported. --GayelKnott 14:47, 15 June 2017 (UTC)

Follow up: "Multiple spouses J" is listed in yesterday's report, so I think this issue is resolved. It still cuts off at "Multiple parents R", but I think that is accurate for now. If that is not the case, please just let us know, and thank you again for staying on top of the Duplicates report. --cos1776 12:10, 17 June 2017 (UTC)
Thanks. It still seems shorter than it should, but at least it is picking up some of the Multiples Spouses. --GayelKnott 01:51, 18 June 2017 (UTC)

Where is the request features page? [29 jun 2017]

hi all,

i am very fond of the http://www.werelate.org/wiki/Special:ListPages/ pages. i was wondering if i could have another page beneath where i could find my family pages?

where should i post such request pls? i could not find such page from the main page

thx Ron woepwoep 21:55, 28 June 2017 (UTC)

You did already. WeRelate:Suggestions/List of families. However, with a large backlog of suggestions and apparently no software development going on, it may be a long time coming. --Jrich 22:01, 28 June 2017 (UTC)

thx @Jrich

any way i can help?

i am wondering if wiki is the right way to enter the future.

is it still on course with developments like MVC and DDD?

don't know, just asking.

thx Ron--woepwoep 22:11, 28 June 2017 (UTC)

Try using the Search page. Put Family in the namespace and your user name in the keyword field. --Judy (jlanoux) 00:21, 29 June 2017 (UTC)

This (pretty much) works if you use the prefix and exact user name ("User:Woepwoep"), but not just user name ("WoepWoep"). If you are logged on, you can get the same result, it appears, by skipping the keyword field but choosing "Watched only" from the drop-down list at the right. --robert.shaw 01:13, 29 June 2017 (UTC)
yes thx. the list is so great because it allows me to search for ABT while ordering dates old to new. woepwoep 02:53, 29 June 2017 (UTC)

Consensus on features to implement this Summer? [3 July 2017]

Can the group come to a consensus on a list of features to implement this Summer? An ordered list of 3-4 suggestions would be great.--Dallan 03:13, 29 June 2017 (UTC)

a list of families, like a list of persons, would be my #1
alternative = that in the search box i can search for the string 'ABT' (case insensitive) combined with following gives me the list of people and families to further investigate.
thx Ron woepwoep 03:31, 29 June 2017 (UTC)
I've also had a request to filter out cemeteries when entering a place name for any fact other than Burial or Alt Buria--Dallan 04:04, 29 June 2017 (UTC)

Source text boxes allow a simple carriage return to define a new line. The Personal History box does not, and I wish it would. I am forever adding <br> to other people's gedcom-delivered notes to make them more readable.

Alternately, the Personal History box has icons for bold, italics, links, etc. The Source text boxes don't. Bold is useful in Source Text to identify the Person in question in a list of family members taken from a census.

Regards, --Goldenoldie 09:45, 29 June 2017 (UTC)

Not sure of the coding reasons for this, but functionally these two boxes are different and some of those formatting functionality is in recognition of those differences, e.g., listing census records versus writing flowing prose. But this is probably not the best place for a discussion of the pros and cons of each user's favorite ideas. I know DataAnalyst recently did an extensive review of the suggestion list, and suggest getting her input. What is the method for establishing consensus? I thought the number of people watching suggestions was going to provide a measurement of this. --Jrich 13:28, 29 June 2017 (UTC)

Could we have a "form" similar to the one used a few years ago ? Once the list is determined, all of us can check the features we prefer, beside our user name. On the Find A Grave Template, I'd like to see something other than "Vol/Pa" in the space where the Grave link is placed.--SkippyG 15:34, 29 June 2017 (UTC)

Jrich is correct. We already have a process for submitting and voting on Suggestions that works pretty well when the resources are available to do the programming required for most of them. That has been the missing piece for a while. The good news is that we have some help on the way now, so please take some time to review the WeRelate:Suggestions list again, both to vote for or update those that already exist and to add your new suggestions to the list. Many date back a few years and may no longer be relevant. It would be very helpful if we could get a more accurate idea of what the community considers to be most important today. Thanks for your help, --cos1776 16:09, 29 June 2017 (UTC)

Is there any possible way to get a list of all the suggestions that I'm watching? If so, would make it easier for me to put them in some kind of priority list. But, yes I thought the number of watchers kind of created it's own priority list. But I realize even that list has to be filtered by what is doable and suggestions too complex or time consuming will drop off the list. So the 'most watchers' list should be compared to our personal 'would be most helpful' list to create a final list for us to 'vote' for with Dallan having the final say. --janiejac 23:25, 29 June 2017 (UTC)

Yes, it is possible to see all the suggestions that you are watching. Do this: Go to the Search dropdown "All" page; on that page, select the "WeRelate" namespace; in the "Page title" box add "suggestions"; check the "condensed" option; select "Page title" Sort-by option; select the "Watched Only" option; and press the Search button. --robert.shaw 21:32, 2 July 2017 (UTC)
Thanks! That does help. Since I like/watch so many of these, I want to better prioritize my wish list. Since we can't have it all perhaps it will help if we all pick our 10 most wanted. Such a condensed list might be more reliable than an just counting watchers on the older list. If everybody would post your 10 most wanted list, I'd be willing to help count and sort everybody's list for DataAnalyst. --janiejac 01:11, 3 July 2017 (UTC)

The highest priority based on "votes" (people watching) is to remove cemetery places from all place prompting other than for burial/alt burial facts. There is no discussion that would make us hesitate to do this one, so I would suggest that Dallan start with this while we allow the community to prioritize the rest through the "watching" system.

Based on a recent analysis, I would suggest that to-date, the other priorities that are ready for Dallan to work on are:

  • change handling of edit conflicts (8 watchers)
  • ability to merge MySource pages with regular sources (7 watchers)

By the way, I recently merged several MySource pages with Sources with seemingly no problem.--SkippyG 23:52, 2 July 2017 (UTC)

Other priorities either do not require programming work (e.g., Assertions, which I believe requires agreement on conventions), require a bit more work to settle on the exact request, or require extensive work (e.g., upgrade Wikimedia).

The assertions don't need any programming support - nor do I think there's any special benefit (for them) in the wikimedia upgrade (though I support upgrades to SW infrastructure in general). They could benefit from a slightly more nuanced fact sort - that made use of both date and fact type. For example, the reference number fact really belongs at the end of the fact list display. A residence fact, even absent a date, should appear after birth and before death, etc. Beyond standardizing the input and display of some types of facts, the assertions can be used by software that works over the WeRelate database. At present, I rely upon the Wikidata and CohabitationWithoutFormalities assertions for a program that compares WeRelate information with equivalent content in Wikidata. The "TwinBirth" template isn't presently used by software, but could be used to recognize when multiple simultaneous births are not in error. --jrm03063 17:43, 30 June 2017 (UTC)

If anyone has a strong objection to having Dallan starting with the 3 suggestions above (cemetery places, edit conflict and merging MySource pages), please add your comments to an alternative suggestion (not this page) to champion why it is important, and/or watch if it is already explained adequately. I will try to find time over the next few weeks to review suggestions with more than 5 watchers to determine the extent of consensus and to see if we can make the requests crystal-clear where there is reasonable consensus.

Stay tuned.--DataAnalyst 01:46, 30 June 2017 (UTC)

French accented characters [5 July 2017]

Can someone tell me how to present French accented characters (like "é") in WeRelate? Right now I am using copy-and-paste, but it is not always convenient.

Is this a topic in a FAQ somewhere?

Thanks. --Goldenoldie 12:54, 1 July 2017 (UTC)

i use keyboard US-International then when i type ' followed by e i get é--woepwoep 13:02, 1 July 2017 (UTC)

I have a "Cheat Sheet" page in my user profile. I made this many years ago when I was new at the wiki. In there, I have a list of all the characters and what to type for them. For example: your é is typed: & eactute ; (all joined together) (Can't get nowiki to work!) If you know the names of the characters,this is pretty quick and you don't have to change keyboards. --Judy (jlanoux) 13:56, 1 July 2017 (UTC)

Many thanks. Judy, I have bookmarked your cheat sheet. The vitals ones have been copied to mine. BTW, your link to Excel to Wiki is now dead.

/cheers, Pat --Goldenoldie 14:52, 1 July 2017 (UTC)

I usually just copy-paste from http://www.ascii-code.com/ which contains what I need for doing transcripts. -Moverton 16:53, 5 July 2017 (UTC)

Do you wish that WR pages loaded faster? [4 July 2017]

This is a shameless campaign for votes for the recent request WeRelate:Suggestions/Site speed - request for faster loading. If you are tired of waiting and waiting (some days) for pages to load, open or save, please consider casting your vote to implement the suggestion above by going to the page and clicking "Watch" in the left menu. If improvements can be made, we can all be more productive.
Thank you for your consideration and Happy (almost) 4th of July, --cos1776 15:03, 3 July 2017 (UTC)

Already voted! The length of time it takes for pages to load more often than not is a major pain. Would also appreciate an explanation of why. --GayelKnott 15:11, 3 July 2017 (UTC)

Would this improve the following. Sometimes when I get "on a roll" entering a dozen or so children on a Family page, I get a message saying I'm entering info "too quickly", or is this another issue ?--SkippyG 00:26, 4 July 2017 (UTC)

I think that may be another issue having to do with the page change limits set by the program as a way to stop spammers. I am not certain if page loading time is part of the calculation, but even if it is, the rate is usually set such that humans do not normally achieve it. Personally, I have never encountered that message. You must be really fast! :) Has anyone else encountered that message and does it happen on a regular basis? --cos1776 17:50, 4 July 2017 (UTC)

Suggestions: Upgrade MediaWiki [16 July 2017]

Concerning the Suggestions/Upgrade MediaWiki. After reading the current status on this suggestion, I feel the need to comment that those who favor this suggestion need to 'sell' the rest of us on the idea. It might be a great idea but it will be expensive and need community support. So if you really want this to be implemented, tell us the advantages and disadvantages of it. Tell us why we should rally around this idea. Or not. --janiejac 23:04, 3 July 2017 (UTC)

Even if it's perfectly functional - older software infrastructure becomes problematic as time goes on. People won't be testing it with and alongside newer systems - it gets harder to find people who really want to work on it. If you encounter bugs - there's really no chance of getting them repaired. All that is true even if we don't take advantage of any of the capabilities of a more modern version of MediaWiki software. I believe that newer MediaWiki software has a programming API - which would certainly facilitate things that I've been trying to do. I can do most of what I want with some brute force approaches - but newer software running the WeRelate server might make my life and tasks easier. --jrm03063 23:46, 4 July 2017 (UTC)
jrm - I hope you don't mind that I added a link to your comment (no objection - --jrm03063 :) ! ) 16:49, 5 July 2017 (UTC)). Right now, WeRelate is like a VCR player. You might have a TV setup at home that still works fine with the VCR and you might only have a little trouble finding a repairman around who is still willing to work on the VCR if it breaks. But when you go to upgrade your TV, you are going to find that most will not connect to your old VCR without special adapters and some will not connect at all. If you can make a connection, you might find that the video quality is not as good as it used to be, and the only VCR tapes you can find are at yard sales and second hand stores. In a few years, you will no longer be able to find any TVs that can connect or any repairman who can help and you will no longer be able to watch videos using your VCR. Our database is like the video and our infrastructure is like the VCR. Those who wish to upgrade the infrastructure recognize that if we want to keep being able to access the database that we have all worked so hard to create, we must keep upgrading our method of access. If we say that we are not going to upgrade, then we are agreeing eventually to be obsolete.
Rather than rejecting an upgrade completely, I wish we would explore alternative solutions. WeRelate has been heavily customized which makes it more difficult to upgrade. At one time there was talk of re-examining many of those customizations to see if anyone is actually using them or if they could be stripped out or modified. I don't think that was ever fully fleshed out. If we want to open up this conversation again, I would recommend that we begin there - what do you use most frequently and what can you live without? I'm sure the answers will be varied, but I would bet that we can settle in on some features that can be eliminated to streamline an upgrade. Would y'all like to open up that conversation again? --cos1776 15:57, 5 July 2017 (UTC)
It's definitely appropriate to see what features have really proved useful - and which ones didn't pan out. That would important even if we were not looking at an upgrade - it might let us cut down the size of the code base that we have to maintain. But fortunately and unfortunately - WR has so blended in with what's in an ordinary Wiki - it's not easy for those of us (who don't know the code base) - to know what parts/modifications WR carries beyond the base MediaWiki software. Of course there's the explicit support for GEDCOM-style content in customized Person and Family pages - along with code that automatically creates reciprocal family links (for example - adding a child to a family automatically adds a link from the child to the family). But what else is out there - and how does it work? Is there a list of upgrades that constitute how WR upgrades the base Wiki - such that we can discuss the utility of different parts of the system? --jrm03063 16:49, 5 July 2017 (UTC)
Seems like I remember such a list from a few years back, but I am on my way out the door, so will have to do some more digging later. In the meantime, the base code is posted at Github. --cos1776 17:02, 5 July 2017 (UTC)
Does somebody need to set up some kind of list of features that we could check off - like yes I use this, or no I don't use it? For example, I never use the Family Tree Explorer function. Maybe I'm missing something good, but it just never clicked with me. --janiejac 02:57, 9 July 2017 (UTC)
Janie - I believe that FTE is the only way to copy a tree from one user to another. So when you share your tree with someone else, they have to use FTE to copy it so that they are watching all the pages (without having to watch each manually). That is about the only thing I use FTE for.--DataAnalyst 03:36, 9 July 2017 (UTC)
It would be nice if someone could define the cost. I assume there would be parallel development until all of the existing features of WeRelate are incorporated into the current version of MediaWiki software, followed by moving the data over to the new system. -Moverton 17:04, 5 July 2017 (UTC)
Cost - see the updated suggestion - it is in there. Given the limited resources for software development, I would assume that if we could raise the funding for this, all other development would halt until the upgrade was complete and critical bugs introduced by the upgrade fixed (preferably as much in the Sandbox as possible, rather than on the live system).--DataAnalyst 03:09, 8 July 2017 (UTC)
Is any attempt being made to develop a contingency fund for when we do need major upgrades just to stay viable? Personally, I would rather forego smaller upgrades, or pay for them through an annual fund raising campaign, while also trying to build up the funds that will be needed for a major upgrade.--GayelKnott 04:35, 9 July 2017 (UTC)
I'm with Gayel on this. We may be concentrating on small suggestions and improvements while ignoring the risk of becoming obsolete because we failed to update the software. I don't know programming but this talk of VCRs becoming unusable brought home the importance of staying up-to-date. We don't know how much Dallan envisions being available for summer improvements. Perhaps knowing how much is available to work with would help the discussion. Just looking at the suggestions list, I realize that software updating is high on the wish list! Maybe we should look into this a bit deeper before writing it off as impossible. --janiejac 17:48, 9 July 2017 (UTC)
Ouch! I should have read that suggestion more thoroughly! That cost is a big hurdle! No volunteer programmers around??
I encourage others to join me in making a recurring financial commitment to WeRelate. I don't know that we have anyone around with a spare $5K-10K in cash or services - but more people making a regular monthly donation could really add up. I don't like formal pledges like they do with public broadcasting - this is just deciding to cut an additional tiny check at monthly bill time. Using my credit union's bill payer system - a couple mouse clicks and done - no surprises on your credit card bill. Routine, pain free, and easy to document as a charitable donation at tax time!
Look at it this way - Dallan's wife (I think?) cashes the checks I send each month. She's already going to the bank - so go ahead - send a $5 or $10 check! --jrm03063 14:57, 10 July 2017 (UTC)

Sounds as if the software update is the most important thing we should do, but I don't think we'll get the donations to tackle it in the next month or so. If some others are like me, I pay my "No-ad" fee and add a little extra as I can afford; I can't do a monthly (perhaps an additional donation), even though $5 or $10 doesn't sound like much. Should we have a year-long campaign, with donations earmarked "general" or "upgrade", and see where we stand at the end of the year ? In the meantime, improvements that are less dependent on the upgrade could be done now. Neal--SkippyG 17:07, 10 July 2017 (UTC)

I only offer the recurring donation suggestion so that people will think about whether it's something they can do. I realize that won't be everyone... --jrm03063 18:10, 10 July 2017 (UTC)
As a matter of curiosity, is there any way to count the number of 'active' members? A year or so ago when folks were so upset about embedded ads, there appeared to be enough people willing to donate something in order to take care of the site, but when nothing came of that, now I wonder how many are left to be still interested and willing. Any way to tell? There is a big difference between the potential to raise $ from 500 people compared to 30 people. So what are are chances?
Could we accumulate some pledges? I'm willing to pledge to give a certain amt if and when there are enough accumulated pledges, but would hesitate to give and then discover there wasn't enough interest to go ahead with the plan. --janiejac 17:56, 16 July 2017 (UTC)
Janie, an interesting idea. For what it's worth, I'm rather like Neal (Skippy), above, in that I do make a couple of reasonable donations a year. If there was an on-going campaign to raise funds for up-grading software, I could probably squeeze more out of my fixed (and sometimes limited) income. --GayelKnott 18:17, 16 July 2017 (UTC)

Recently i learned about use cases. If we go from scratch, these use cases might help.

For example: one of my most basic use cases is to add a person page to WR. Another one is to add a family page to WR. A third use case is to edit a person page. A fourth would be to merge two persons' pages into one.

This way we could find out who uses what, without going into detail yet. woepwoep 05:31, 9 July 2017 (UTC)

Active member count [17 July 2017]

Janiejac asked an interesting question - "is there any way to count the number of 'active' members?"

Interesting challenge!

I have tried to answer this by starting with the threshold used on wikipedia of five edits per month. I tried to get as long a list as I could by revising the "Recent Changes" query to show 30 days, namespace "Person" and the last 5,000 edits (the most it would show). [1]

This actually shows only a week's edits, but hopefully will give the start of an idea of how many active editors there are on WeRelate.

Copying the result into a spreadsheet (pasting as "unformatted text"), it can then be manipulated to show the users. The simplest one is where there is a single edit, such as this:

N    21:43 Person:Samuel Colburn (7) (diff; hist) . . Jrich (Talk | contribs)

Here I have used a formula to identify the username, located between ". ." and the "Talk". I'm using OpenOffice, but the syntax in Microsoft Word is similar:

G3: =FIND(". .";A3)
H3: =FIND("Talk";$A3)
I3: =IF(ISERR(G3);"";MID(A3;G3+4;H3-G3-6))

For multiple edits, they are in the format:

     20:34 Person:Leslie Steiner (1) (5 changes; Page history) [Sorghumgrass; Delijim (4×)]

or, if it's multiple edits from the same user:

     20:33 Person:Mary Hutchings (10) (2 changes; Page history) [RichardK (2×)]

I have only identifed the first user for simplicity, although I acknowledge this will give an undercount overall.

J14: =FIND("[";$A14)
K14: =FIND(";";MID($A14;J14;100))
L14: =FIND("(";MID($A14;J14;100))
M14: =IF(I15<>"";"";MID(A15;J15+1;IF(ISERR(K15);L15-3;K15-2)))

Combining both single & multiple edits into a single column:

N14: =IF(I15<>"";"";MID(A15;J15+1;IF(ISERR(K15);L15-3;K15-2)))

This gives me a consolidated list which, using a sorted PivotTable gives me the following totals:

1 Susan Irish 346
2 Jrich 245
3 KleiHMv 190
4 DataAnalyst 176
5 Jaques1724 85
6 Loughner 85
7 Goldenoldie 68
8 Neal Gardner 61
9 Sorghumgrass 58
10 Beatrijs 50
11 Delijim 43
12 Kdrost 29
13 RichardK 29
14 White Creek 26
15 Moverton 24
16 Amelia.Gerlicher 21
17 Bolan 18
18 RolandHenryBakerIII 17
19 JuliaHogston 16
20 Melderick 16
21 GayelKnott 15
22 Grey 13
23 Jrm03063 11
24 Bronquest 10
25 Normiejac 10
26 Burgjoh 8
27 Pahawkins 8
28 Rebejackson 7
29 Acurley 6
30 Babo 5
31 Btomp 5
32 Rebekah Carlisle 5
33 Samples 59 4
34 Dbarton19 3
35 Diane Terpstra 2
36 Maximiliano 2
37 Pkeegstra 2
38 Sjoerd Jelle 2
39 Ts 2
40 Cos1776 1
41 Dskousen46 1
42 Jbigwood2 1
43 Julia Hogston 1
44 Mz28yo 1
45 Tlc356 1

So, depending on how exactly you want to define "active user", there were 39 people in the last week who made two or more non-minor edits to WeRelate Person pages.

I have bolded those on the above list who are also commentators here. The method clearly isn't infallible as my list is missing the following other users:

woepwoep - looks like I just missed him in the cut-off
janiejac - her only edits recently were all marked as "minor"
BobC - just missed in the cut-off
Khaentlahn - just missed the cut-off
Dallan - no recent contributions

At a guess, I would say that makes around 45 regular contributors. Not sure if the summer holidays understates that number. AndrewRT 22:55, 16 July 2017 (UTC)

Thanks for all your work to come up with an answer to my question!! That required talents that I don't have!! Perhaps the upcoming voting on suggestions will also give us some idea of how many folks are interested in getting those suggestions implemented. I think Dallan is planning to use the money from ads and/or donations from 'please no ads' to fund the summer improvements. But I'm also thinking having an ongoing list of pledges toward upgrading mediawiki is going require more participation than just these active people. A pledge list wouldn't involve actually handling any money, but what about someone with the talent setting up a separate page to describe what we're trying to do and let people sign up as a pledge to be given when the totals reach a pre-determined amount. You could somehow hide the amounts as it's not a good idea to be public with that; but show the total promised as of the current date. (I know, situations change and some will back out, but hey, it would be a start!) Any comments on the advisability of doing this? Or am I having wild ideas? --janiejac 02:00, 17 July 2017 (UTC)

I think we need a projection here. At one time Dallan gave us a basic idea of how much income is generated by ads, and general operating costs. Perhaps someone knows where this was discussed - 2016 or 2015, 2014 ? I think we need a $ goal, and an average monthly amount to achieve the upgrade, especially if we are projecting the upgrade for 2018. Perhaps we could encourage "ad-free" contributors to add that $5 or $10 amount to their next payment; I think most of the "ad-frees" are in a 2 or 3-month period and may be a similar list as generated above. I just paid mine at the end of May and believe most are in a period surrounding that month. Neal--SkippyG 14:04, 17 July 2017 (UTC)

Also, do we tell new contributors how they can remove adds from their account ?--SkippyG 14:16, 17 July 2017 (UTC)

I think Dallan has already given a projection of from $5,000. to $10,000. Perhaps because I'm a (retired) bookkeeper, I think of fund raising for the one-time wiki upgrade should be separate from the funds available for normal suggested improvements. If we don't keep it separate with a specified estimated goal, how are we, or Dallan, to know if or when the goal was reached? And unless I can see that there are enough folks interested in this to make it even feasible that we might be able to raise $10,000 then I'm not motivated to even begin. So, yes, this would be a long-term project. It has taken two years just to accumulate enough funds to activate the normal suggestion list. If we don't separate or designate the funds, the normal suggestions will probably eat up any extra funds. I'm willing to pledge funds to a visible list. If others add their names and I see that yes, it will be possible, then we can go for it. But I'm not willing to just give a bit more each time I donate hoping that sometime in the far future, those funds will be used for the upgrade. I'm talking about motivation to give; I guess I just need a specific project to give to; not a generalized list of hoped for suggestions. --janiejac 14:56, 17 July 2017 (UTC)
@SkippyG - per Dallan's Watercooler posts (May 2016) [2]:
"... WeRelate makes roughly 75% of its income from ads and 25% from donations. Specifically, it's about $600/mo from ads, about $50/mo in donations, and $2,000 from the fundraiser last Summer. ... It costs roughly $350/mo to pay for the servers. The ads are a necessity to keep WeRelate running. WeRelate does not get enough donations otherwise. A $20/year donation exempts you from ads. ... " ... and ... " ... If things keep going as they are, the MyHeritage ad is on track to generate over $1000/mo - almost twice what the google ads are generating. ..."
We have not been updated on the $1000/mo projection to know if it panned out, so that is something to pursue. Also, we do not currently include information about removing ads in the standard Welcome message to new users. We certainly could, and I think that is a great idea! --cos1776 15:48, 17 July 2017 (UTC)

So, if I'm taking everything into consideration correctly....we need an updated figure for WR's monthly income with a rough figure of how much, if any of that income could be earmarked for "Update", giving us a rough figure per month needed by donations...followed by a decision of how long we hold this campaign; 6 months, 12 months, 18 months ? In addition, can we afford, in the meantime, to make smaller improvements ? Or hold off, and see how the campaign goes ? If we have current monthly income $1000 or plus, we might have a shot at "updating" sometime next year. Neal --SkippyG 16:37, 17 July 2017 (UTC)

Request List [19 July 2017]

A list of potential software improvements has been created and needs to be prioritized by community voting. Please see the request list for more information. Note that voting is open, but some items will not be ready to be voted on for another day or two. In the meantime, you may wish to review the requests.--DataAnalyst 02:18, 18 July 2017 (UTC)

All items have now had points assigned. Note that one new request was added as well. Please ask for help if you have trouble figuring out the voting system - I can't tell if I made the explanation clear enough. Thanks--DataAnalyst 02:08, 19 July 2017 (UTC)
I would prefer to have Dallan vote my "points". He has better visibility into what makes the most sense from a development perspective. --jrm03063 14:44, 19 July 2017 (UTC)

Suggestions: you get 12 Votes [19 July 2017]

Come on folks! Let's get this done! DataAnalyst has done a major job laying it all out for us. A bit tedious yes, but we've been waiting for this chance to get some of these suggestions implemented. So use your 12 votes wisely - spend them on the suggestions most important in your opinion to either improve the functionality or professionalism of the site. See this link to vote! --janiejac 16:20, 19 July 2017 (UTC)

Ok, well let me express my appreciation for the opportunity to vote - and the effort put into providing a way to do that. It does matter. I'm committed to WR and contribute as I can. That said, the suggestions available for implementation strike me as very distantly second to getting us to a newer Wiki software base. I suppose it would be nice to see "reference number" facts sort to the end of the fact list - but that change won't make anything I'm doing easier. So I'm inclined to abstain and/or defer my vote to Dallan. Thanks again for the opportunity, and please don't interpret my non-voting as lack of appreciation or interest in WR. --jrm03063 17:31, 19 July 2017 (UTC)

I appreciate the thoughts given by jrm03063, and respect his choice to defer to Dallan...however only 4 of us have expressed opinions re: improvements. I personally hope that I don't have that much power {;>). Even if you only vote for one improvement, please help make this a group decision. ANYBODY can chime in. Just Neal--SkippyG 23:06, 19 July 2017 (UTC)

With all due respect Neal, voting just started this morning. Many items were not weighted until then meaning one could not partition their 12 votes until then. Not clear what the deadline is since one doesn't seem to be stated (did I miss it?), but I suspect many people may only log in once a week due to work, etc. --Jrich 23:43, 19 July 2017 (UTC)
DEADLINE: Sat. 29 Jul 2017, as it says at the top of the Request List page and the talk (voting) page. I agree it's rather early since what's being voted on just settled down on the 19th. --robert.shaw 23:56, 19 July 2017 (UTC)

Just an encouragement, folks, not a command. --SkippyG 00:16, 20 July 2017 (UTC)