- Everyone, There have been some issues in the past that have restricted us from taking updates of the standards catalog into nFS. The last time that aMessage 1 of 35 , Jul 1, 2010View SourceEveryone,
There have been some issues in the past that have restricted us from taking
updates of the standards catalog into nFS. The last time that a standardize
place catalog was updated was several years ago. And although your feedback
on standardized places have been taken and the catalog updated, you never
saw the fix because of this problem.
The release that was put out in June has been updated with the latest
catalog that diligent engineers have been working to improve for years. We
also have changed the way that standardized places are chosen and have more
strongly separated the place you enter from the standardized place.
Now you can enter a place and it will pop-up with suggestions from the
database, but if there are none you believe are close enough to select so
you don't have to keep typing, then just don't select any from the
drop-down. Then the system will attempt to match what you entered and fill
in the standardized version of the place. If you don't believe the
standardized place is close enough, then click on the arrow next to the
standardized place and pick the closest one. By doing this we keep your
original place data but also have the closest standardized place.
If entries were made by the system or others that have a poor choice for a
standardized place, then just enter another opinion and correct it with the
technique above and then make sure your entry is selected in the summary.
We have now corrected the issues with taking the standards catalog and
expect to have more regular updates as we take your feedback and correct the
On Tue, Jun 22, 2010 at 8:17 AM, Bill Buchanan <
>[Non-text portions of this message have been removed]
> Venita, Ron Tanner, and others,
> I have come across a Standard Place Name that is 1000 miles from the real
> place. It can be a mess. "Tupper District, Manitoba, Canada" becomes
> in British Columbia 1000 miles further west! In the latest release .991,
> western Canadian place names have non-existent "Division" numbers inserted
> in them, as I mentioned in a former post.
> I know a lot of investment has been made in the Standardized Place Names,
> but I worry that this could make new.familysearch.org the laughing stock
> the genealogical community when it goes public. I would rather see no
> standardized place names than to see them be wrong.
> I love nFS, I find it a great improvement over what preceded it! If we are
> going to have standardized place names, maybe FamilySearch could allow us
> to edit them. It seems obvious that whoever is creating them now has been
> given an impossible task. The alternatives that I see are to either scrap
> the Standard Place Names or else get a lot more help. Maybe the Area Family
> History Advisors (sorry Peter) could be given the list of proposed Standard
> Place Names for their area for review, or the Stake/District clerks? None
> us may be infallible, but we need to be progressing towards our goal.
> I manager I once had would say, "Never tell me about a problem unless you
> can propose a solution!"
> Bill Buchanan
> website: http://billbuchanan.co.cc
> blog: http://billbuchanan.blogspot.com
> On Mon, Jun 21, 2010 at 8:52 PM, Venita Roylance <venitar@...<venitar%40mac.com>>
> > This is especially for Ron Tanner, but anyone is welcome to respond:
> > I have Welsh ancestors - my father was Welsh. Some of the Welsh place
> > have been connected to standardized place names which have no
> > the the original place. For example, for my grandmother, Margaret THOMAS,
> > one opinion of her birthplace is shown as "Pen Heoly Gerrig,
> > Wales," an incomplete and slightly misspelled but accurate place name.
> > standardized place name is "Danielsville, Northampton, Pennsylvania,
> > States." (See PID KW8N-3P4) Where in the world did that come from??? I
> > disputed the place, not because the place is incorrect, but because the
> > standardized place name is way wrong. How can the wrong standardized name
> > removed and a more accurate one be linked? I did not submit the data.
> > Venita
> > PS: This is one example. There are other similar mis-connections in my
> > Welsh ancestral data.
> > .
> [Non-text portions of this message have been removed]
- Terry, You have highlighted exactly the problem as I see it. Bug reports are either not reaching the people who can have them fixed, or they get ignored onceMessage 35 of 35 , Jul 5, 2010View SourceTerry,
You have highlighted exactly the problem as I see it. Bug reports are either
not reaching the people who can have them fixed, or they get ignored once
they reach that level.
When you look at the list of long-term bugs, there seems to be no reaon why
they could not have been fixed by the part-time efforts of a single
programmer long ago.
The main support loop generally works well where no bugs are involved. But
where there are bugs, the patron gets a pat answer rather than a bug fix. At
that point the patron is either placated or infuriated depending upon the
The only way of reaching the engineers is by asking that the case be closed
as an "enhancement request", but the only promise there is that "someone"
from engineering will read the case. There is no promise of any action.
So many good things have been accomplished over the past 3 years or so. It
is sad that persistent bugs continue to spoil the experience, with no
reasonable mechanism for having these bugs fixed.
I am glad to see participation by Ron Tanner on FHCNET. I wish we also had a
process for contacting David Rencher and others. I think that FamilySearch
managers may be the only route available to get engineering to address some
of these long-term bugs, most of which should be easily resolved. Someone
sets the engineering priorities.
Continue to encourage improvement. nFS has a great future. It needs our best
efforts to get there.
On Mon, Jul 5, 2010 at 9:56 AM, tmason1 <tmason1@...> wrote:
> On Fri Jul 2, 2010 Bill Buchanan wrote in FHCNET@yahoogroups.com<FHCNET%40yahoogroups.com>to the Subject of 'Totally wrong standardized place name' about the [EDIT
> I have another bug to "Bug" you about but I'm really writing about a
> The other Bug:
> One of the purposes of new FamilySearch is TO COLLABORATE. A person who has
> claimed a link legacy is in nFS with editing rights but WE HAVE NO ABILITY
> to communicate with them. This feature was working in version .92 of nFS but
> hasn't worked since. That is over two years ago.
> In KD:102671 it says "...the resulting ownership contributor contact name
> will appear in the new FamilySearch as DavidBlack[dblack5535003]." Then it
> says "Even if the patron has included his or her contact information into
> their new FamilySearch profile, the contact information will not be
> displayed on the claimed legacy submission. This feature will be added in a
> future release."
> The question that needs answering is: "Why won't the Engineers fix the
> problem identified in KD:102671 and display the contact information for
> contributors who have claimed a link legacy contribution?"
> One reason may be that the rollout of new.FamilySearch.org<http://new.familysearch.org/>has not been completed. The Asian temple districts have not yet been brought
> on-line with the rest of the Church. Once that happens, maybe, maybe then
> the resources of the department might address some issues like these two
> Like you, in my previous life I also worked with programmers. In my
> frustration as I've dealt with the FH department, I've thought "When a
> person gets a little authority, as they suppose, they tend to place others
> in a subservient role."
> I think if the feedback process focused on meeting the needs of the user,
> then the users and troubleshooters would be responded to in a more amenable
> way. I think you like I am, are looking for a working relationship with the
> nFS authorities that is more invitational where you are treated with respect
> instead of feeling ignored. I have often felt placated by being put in my
> place by a process that keeps the engineers in an environment where they can
> freely work without interference. That is good, unless that is, they are
> involved in building castles in the sky and the needs of the users are not
> being met. Sometimes I wonder if the programmers have ever done any family
> history research.
> If those in authority perceive themselves as being servants to the needs of
> the user then all of us would feel as participants working on the same
> project. However if the user feels ignored, invisible, or continues to be
> frustrated, so that the user does not feel respected, then I suggest that
> the process of dealing with these "bugs" needs to be handled better by those
> in charge. That is how I perceive your expression of being bugged by the
> edit "bug".
> Ofter, I think the user does not understand the issue and they communiate
> their problem and need poorly. (That is not usually the case with you Bill.)
> It is important that the process focuses on "Ask Clarifying Questions".
> There is room for all of us to improve in the process. Matthew 7:7 teaches
> "Ask, and it shall be given you; seek, and ye shall find; knock, and it
> shall be opened unto you."
> The FH consultant working in a Family History Center is Tier I support for
> all local patrons. Consultants are the key to a successful Family History
> program. When they can not correctly resolve the patron's needs, they need
> the support Tier II team to help them clarify and resolve the problem. The
> question I ask is how well are the Tier III support personnel providing
> accurate and timely responses.
> When I refer to this group, I do not mean the 20+ specialists we know as
> CHQ support. I mean the engineering staff that OFT and JIRA tickets are
> forwarded to. I think their timely and accurate responses are the weak link
> in the chain of serving the needs of those they are called to serve.
> Terry Mason
> On Fri Jul 2, 2010 Bill Buchanan wrote In FHCNET@yahoogroups.com<FHCNET%40yahoogroups.com>
> Subject - Re: Totally wrong standardized place name
> > EDIT "BUG"
> > You are describing the Edit bug that has been plaguing us since about
> > version .83 of nFS. Sometimes the Edit function works, other times it
> > not. When it doesn't work, the corrected place name appears when you
> > Edit, but it fails to appear in Details or Summary. A fix has been
> > for 2 years, but I suspect it may have been forgotten. (I used to do
> > computer programming as a hobby, and I don't think it would be hard for a
> > programmer to fix it. Somehow the contents of the Edit field are not
> > stored in the database.)
> > Where Standard Place names are concerned, I see that those for western
> > Canada have been corrupted by inserting non-existent Divisions where many
> > other places would have Counties.
> > Bill Buchanan
[Non-text portions of this message have been removed]