¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io

Re: Projects for Sub-groups of U106


 

¿ªÔÆÌåÓý

Hi folks,


This topic comes up every now and again, and it's something we think about seriously every couple of years. The decision is essentially a balance between several issues, and a question of where focus is most important.


The R-P312 groups have taken the stance that more sub-projects is a good thing. However, what this inevitably ends up with is that many members of sub-projects don't join the over-arching parent project, admins of the main projects aren't always admins of sub-projects, and it becomes difficult for an admin in the parent project to get an overview of the whole haplogroup.


The main benefit of keeping the project together is that we can pool resources. That was more of a concern in the past than it is now, when haplogroup administrators were in charge of maintaining the haplotree, when we were more involved in developing products for FTDNA, and before we had access to systems like Discover. However, it's still important when it comes to providing results to individuals or performing deeper analysis of a haplogroup, to have these results in one place. It's the only way we can answer questions like how rare a set of STR markers are, lets us examine SNP recurrences, probe migrations independently of Globetrekker through MDKA information, etc.


The main benefit of splitting the project up is that smaller sub-projects can take a more focussed look at smaller sub-clades. However, that requires people to take charge of and run these projects. We have had two major sub-clade projects within R-U106 already: the R-L1 project was folded into the R-U106 project as administrators became too infirm to run the project; the R-Z18 project has been very sporadic and now appears completely moribund. There appear a good stream of people who have the capacity to set up a project, but few who are able to commit in reality to running a project for more than a decade. We've found the hard way that a large body of administrators is useful in managing the transitions as people inevitably have to leave. Only the R-U198 project remains functioning well, meaning it's easy for us to forget about them and their members when it comes to dealing with decisions that affect all of us, and meaning that it can be hard for us to provide over-arching results for all of R-U106 because we don't have access to information on R-U198.


So where do we define this balance point? This comes back to what the point of a haplogroup project is. People have different answers to this but, personally, my answer is to find out our shared origins and how our ancestors spread from these origins to get to the present day.


U106/S21 is regularly probed by academic studies, and we now have a fairly good idea of when and where it comes from. Through ongoing research into the Corded Ware Culture and its origins, the academic world is now taking charge of the origins of R-U106 and higher haplogroups and, while it makes an interesting topic for our discussion, we aren't going to beat them to it. However, the academic world has yet to take serious interest in any sub-groups of R-U106 in the same way they have for, say, R-M222. There's no-one except us seriously researching the origins and spread of R-L48, R-Z18, R-Z156, etc., and that's only going to become more true as these haplogroups get smaller. So R-U106 really still remains the upper limit of where the genetic genealogy community has the most impact.


However, it's clear that the R-U106 or any haplogroup project can't look at the details of every family. This is supposed to be the place where surname projects take over. These projects are meant to look at individual families and use genealogy to match them together. This works well in some cases, but the sheer diversity of many common surnames means that this doesn't work well for a lot of people either - the Clan Donald DNA project has done wonderful things, but not really helped with my family! What we're seeing instead are an increasing number of cases where someone wants to take their own family and a few historically related families and put them together. I'm trying to do this in a few places, like my own R-FGC14759 and the Wettin group R-Y17443, and a couple of others I'm taking on, but I can't do this over the entirety of R-U106. This regime therefore sets the lower limit of where a large haplogroup project like ours has a valid remit.


Partly from these historical issues and partly from a desire to retain a vision of the whole, we've so-far always taken the decision to keep the R-U106 project together. However, what we've seen more benefit in recently is being able to scythe historical groups from the project and let individual researchers take care of them. There have been different ways in which we've dealt with this: Gary Blakely's independent R-P89.2 group was the first of these, though I haven't heard from Gary in a while; more recently, Robert McMillan has joined the project solely to take care of the R-Z156 McMillan family, but his help has been greatly appreciated elsewhere. These are just two of the examples - there are several more.


Despite this, it is hard for any one of us to keep an eye on developments over the entire R-U106 haplotree. Consequently, we've ended up with some subtle divisions within the project. For example, my division is R-Z156, so it's usually me that ends up fielding R-Z156 related questions. However, these divisions don't currently run very deep, and division in our administration is mostly related to tasks (e.g. welcoming new members, sub-grouping members, liaising with FTDNA), leaving me to answer questions and analyse data.


Until the situation changes, e.g., if the upper migration patterns of R-U106 are solved, I don't see the R-U106 project splitting up. Our job will get harder, since the number of potential administrators is not growing as fast as the number of testers, meaning we will have to operate in a different way. But I personally think that keeping the project as a single entity for the forseeable future is the right decision. However, this is not a project run for administrators, it's run for all of you. If there are aspects of the project that aren't working well for you, or things that you want from a project that we aren't delivering, then we want to hear about them and try to find solutions to them.


Best wishes,


Iain.

Join [email protected] to automatically receive all group messages.