FTDNA has released their new yTree and is transitioning to reporting Terminal SNPs. This is two major changes at one time - which is creating a good bit of confusion. In my opinion, Terminal SNPs are fine - as long as we continue to use some version of a companion long form so that we can recognise where a SNP falls on the tree. (Even with the regular changing that has to occur to a long form to keep it current, having it is much better - and less work - than not having any easy reference.)
Issues that I see:
1. Terminal SNPs are a very different Format which uses the first letter of the Haplogroup, followed by a dash and then the Terminal SNP. As example, my previous reported haplogroup was R1b1a2a1a1b3c2. (I call this the "long form") My Terminal SNP version is R-L196. In the old system, when someone extended their level of detail, the extra info was added to the end of a long form and it was easy to see the progression. With the new system - position and relationship to other kits won't be understandable without a reference tree. (As example, My R-L196 is R-L2 if you remove the last digit.)
2. Errors: There have been errors in the Tree and errors in the reported Terminal SNP during the roll-out. Right now, things seem to be changing daily - so it's a good idea to lean back and wait for the dust to settle.
3. Transition: The conversion is apparently being made in stages - possibly each night - creating conflicts due to combining the old long form and new Terminal SNP structures. (when I try to update a project, some of the men have a long form and some have a Terminal SNP. And, some no longer have any information. (I assume that this is temporary) This is another reason to wait for the dust to settle.
4. Matching Check - based on matching or conflicting Haplogroups: The old logic was that you couldn't have a "Match" with a man with a different Haplogroup. (yes - we had to examine the shorter haplogroup to make sure that it was the same as the longer one until it ran out of digits. If so, they weren't different)
Example 1 - R1b, R1b1a2, and R1b1a2a1a1b3c2 aren't "Different" - they are simply shorter or longer versions of the same Haplogroup family.long form. These men can be in the same Genetic Family (i.e. "Match")
Example 2 - R1b1a1 and R1b1a2 are Different. These man cannot be a "Match" and will be in Different Genetic Families
5. Mapping: There is no mapping structure built into the Terminal SNP names. The new logic is that each man has a Terminal SNP based on his FTDNA estimate or from his own formal SNP testing.
This will mean that you have to memorize the terminal SNP structure or have a reference tree on hand as you seek to understand whether two men can be related or not - based on their position on the Tree
Example 1 - The three men above (R1b, R1b1a2, and R1b1a2a1a1b3c2 ) are probably reported in the Barton project as R-P25, R-L2 and R-L196. These are all at different points on the same Haplogroup Family long form and are nodes on the same branch of the new yTree. They can be in the same Genetic Family. (note: the L2 estimate in this example is based on matching men who are known to be L2 in the Barton project. Another project with R1b1a2 men may get a totally different Terminal SNP estimate)
Example 2 - I'm not perfectly sure of the translation of R1b1a1 and R1b1a2 - as the FTDNA tree has a different arrangement than before - but these should be R-M73 and R-M269. Whatever is the correct translation from long form to Terminal SNP - they can't be a Match.
6. Color of Haplogroup or Terminal SNP: Note that I am showing Haplogroups in Green or Red. This has always been important, but if anything, it becomes even more important with the new system.
A red designation is used when the Haplogroup is estimated by FTDNA. (the conversion from long form to Terminal SNP will be different from man to man - you can't predict the Terminal SNP for an individual by only knowing his old long form)
A green designation is used when the Haplogroup is based on a formal test of the Terminal SNP (This translation should be predictable and be the same from man to man when converting from the old long form to the new Terminal SNP)
A black designation has been used by WorldFamiles (and others) to denote an estimate not provided by FTDNA (such as a result transferred from another testing company) These are going to be difficult to manage.
7. FTDNA and ISOGG Trees: ISOGG has worked in "real time" on their yTree, while FTDNA has released their new info in batches - typically less often than yearly. This has meant that ISOGG typically has the more advanced (up-to-date) and more complete tree. In recent years, ISOGG has established credibility and is regularly cited in scientific journals. It appears that the ISOGG work was not a reference for the new FTDNA tree that uses Terminal SNPs
8. Differences in FTDNA & ISOGG Trees: There are many differences between the two trees at this point - Naming and arrangement iis sometimes different and the two trees don't include the same SNPs. I haven't checked - but I hope the two trees don't disagree on the structure when considering the same SNPs. The FTDNA tree is reported to be focused on adding the Geno 2.0 SNPs to their prior tree, while the ISSOG Tree had already included much of the Geno 2.0 learning and moved on to the learning from the Big Y and other data sources. Hopefully, the significant differences wiill soon be resolved. For now, it is one more place - and reason - to wait for the dust to settle.
9. For WorldFamilies, there is another issue - as we have relied on the Haplogroup to sort men in a project before detecting the matches that define the geneatic families that we call "Lineages". This still works for much of the tree, but no longer works in "R" - as R, R1a, R1b & R2 are all being reported as "R". Additionally, our Results Tool was not built to handle a random combination of long form and Terminal SNP reporting. (which is what we are receiving from FTDNA today) Both are creating problems for the WorldFamilies results tables. We are working to resolve these - but until we do - you will see all sorts of oddities in the Results Tables that we prepare. (Yes - the user complaints have already started)
Operating with Terminal SNPs without a companion long form name is going to make for a long and painful transition. Making the transition with a much different yTree makes the challenge greater. My opinion is that a companion long form would greatly simplify and ease this transition.
I suggest that you give things time to settle and then that you get advice from your Haplogroup or Surname project administrator before you order any SNP.