Trish and Dave,
I think we can all agree that there ain't no pleasin' everyone in this regard. That is to say that there
will be a certain portion of the members whose plants are not peaking or who will not have had their plants bloom yet during their designated weeks.
In thinking about it further, it's become a very simple question in my mind: how much of the crowdsourcing crowd do we want to service and how much of it are we willing to exclude? And then let the available data set the dates (mitigated by the other identified factors in play, of course). But really, inclusiveness is based on empirical blooming data - not a wished-for schedule.
Ultimately, I guess that means that the gardens themselves are no respecters of off weeks and things fire when they do. So, if having staggered weeks is a more important value than inclusiveness (and it may be, given the work involved), inclusiveness necessarily will suffer. I realize that this is a ton of work generally, and adding these weeks with "peaking" timing adds even more to the load.
If I ran the circus, the
only criterion would be how much of my population am I willing to exclude from participating, come up with a number, and ask the data where to draw the line. Then maybe shuffle a little within a specific exclusionary window to make things fit practically (given the other criteria in play - such as the necessity for some off weeks).
With that in mind, this is what I'd suggest:
1) Conduct a census of members by zone (how many gardeners live in each zone?).
2) Figure out what percentage of contributors live in each zone (what percentage of total gardeners live in each zone?)
3) Apply the exclusionary criteria (mentioned above) to identify the service-to cutoff zone (e.g. if ~75% population coverage is the goal, that means that you add percentage from 9+8+7+6, etc. until you reach 75%)
4) Identify bloom times (peak) for the categories in question by the zone identified in #3 (by any of a variety of methods)
5) Select the week based on #4
6) Re-shuffle the weeks, erring on the side of later rather than sooner (inclusiveness), based on the other criteria that's been identified.
Not my site and it's entirely up to you. I'm grateful for the countless hours fun and edification and community that the site provides for me and others and thank you for that. I brought this to the table not as a criticism, but truly with the hope that some data-based tuning with an eye to inclusiveness might occur (thereby pre-mitigating rather than
ex post facto-ing in the future).
Also,
@zuzu: I think if you'll reread my posts (with a careful eye to what I'm actually asking the data as well as the conclusions that I draw), you'll see that there was no disingenuousness at all on my part...and that the conclusions drawn support the data given the acknowledged and articulated caveats in play. Further, even if I were to include your potential contributions in the roses data (being 100pct generous with the assumptions in the inclusion), that would knock the exclusion rate from 85 to 80 percent in the sample (which happens to be the only extant sample for the question at hand). And that's still pretty untenable for a crowdsourced enterprise.
