Re: [FIRST EMAIL] Stop Build Day Survey
 

You said that:

Why do you believe it is incorrect? The only reason I would ever say a metric/proxy is incorrect is if it had a small or negative correlation with the variable in which we were actually interested. In fact, I might go so far as to say that we shouldn't even use the words correct and incorrect when describing metrics. We should probably only call metrics "useful" to varying degrees. Do you think team retention is not a good metric/proxy for team success? That could be a valid argument. However, you seem to be saying OPR is a poor metric just because some might use OPR to advocate for policies you disagree with under the incorrect assumption that correlation=causation.



Let me give an alternative example:
Atmospheric CO2 levels has been pretty strongly correlated with average global temperature over the past couple hundred thousand years [1]. Thus, most would say that atmospheric CO2 measurements have been a useful (correct) proxy for global temperature. Many others though, will say that CO2 measurements are an "incorrect proxy/metric" solely because they don't want to deal with the possible implications of the correlation existing. On my linked website, it says:

The relationship is not simple, both of these variables play off of each other, as well as interacting with thousands of others. The correlation is still strong though, which makes atmospheric CO2 levels a useful metric for global temperature.


If you disagree that OPR and team success will remain coupled if we eliminate bag day, that is a perfectly respectable position. I don't believe though that it is a respectable position to discredit useful metrics out of fear of that others might misuse the information contained within them.



[1] http://www.ncdc.noaa.gov/paleo/globa...re-change.html

Re: [FIRST EMAIL] Stop Build Day Survey
 

That is sort of a separate issue though. My response was more geared towards promoting FRC with people not familiar with it already.

All I'm saying is that if you did have unlimited access from kickoff through competition season, you could still market it as, an "8 week build season", without much impact on the reaction it elicits from newcomers.

Re: [FIRST EMAIL] Stop Build Day Survey
 

Teams with a small amount of mentors tend to have a low OPR.
Teams with a small amount of mentors tend to be victims of attrition.
Teams with low OPR tend to be victims of attrition.

Solution: Let's fix the OPR problem by allowing teams more plays and/or unbag time.

Possible result: already thin-stretched mentors get more burnout faster, and the attrition actually increases as fringe teams fall away.*

OPR is a symptom, not the disease.

Perhaps this is an example of a conflation of symptoms at which gblake and others have been hinting.

(And the small number of mentors example is one of a myriad of possible challenges teams face. Please don't take my example as a one-and-only offering.)
(Also please don't take this as an opinion of my being pro- or anti-SBD. I honestly don't know where I stand yet.)

*Paradoxically, by dropping some of the low-performing teams, the 'product' will get better and more media friendly. That's a tangent for another day (and another thread methinks)

Re: [FIRST EMAIL] Stop Build Day Survey
 

Ah!
I thought you thought I wrote that OPR and Team Retention aren't correlated. Jim's paper shows that they are.

On the subject of whether OPR would be the useful metric to use gauging team's success, I did intend to convey that IMO the correlation between OPR and Team retention doesn't make OPR the metric to use (focus on, lead with, etc.) in conversations about whether teams are successful.

In the PS: section of another post today, I did mention the domain I prefer. It is very different from the domain containing OPR. What I wrote there was

Re: [FIRST EMAIL] Stop Build Day Survey
 

Then why not give students more time around said STEM experiences by not making them put their creation in a trash bag?

Re: [FIRST EMAIL] Stop Build Day Survey
 

Because students burnout to. If the build season was just one weej longer last year, it would have been great for our small team. But build season always hurts our grades, and adding another week of suboptimal schoolwork would have put many of the students on my team even farther behind. There are still plenty of ways to continue the stem experience, like watch week 1 competitions or preparing for competition. Extending the build season will not expamd the experience any farther than it already is, but wil insteadl negatively the students.

Re: [FIRST EMAIL] Stop Build Day Survey
 

I have yet to hear a truly convincing argument that eliminating bag day would significantly increase the amount of work most teams do.

In all of my FRC experience, I've only ever built a practice bot once, but I've worked on something or another between the end of build season and the start of competition every single year.

So, this doesn't seem to me an issue of "not increasing the workload." We might be able to reduce the workload were we to instead implement harsher restrictions on the ability of teams to work after bag day, but it is not clear to me a) how these would actually work in practice and b) whether that's actually desirable in the first place.

Re: [FIRST EMAIL] Stop Build Day Survey
 

I understand your issue.

However, upon a bit more investigation I think ending SBD will actually help students to NOT burn out.

Here's why:

Lets say a students spends 5hrs/day 5 days/wk at build, that's fairly common among teams from my understanding. That would equate to 25 hours a week, and over the 6 week build season (although that in itself is a myth), would mean the student spent 150 hours of their time at robotics.

Now, lets get rid of stop build day.

The build season now becomes longer, and the robot doesn't have to be done in 6 weeks. This opens students up to not having to cram hours in during the 6 week period.

Let's decide to enter a week 2 competition. Now we have 9 weeks to prepare a robot, instead of 6.

Let's also cut down hours/day to 3.5, giving students more time to focus on homework, or other activities they may want to participate in.

3.5hrs/day and 5 days/wk is 17.5 hours/wk, 7.5hrs/wk less than the current schedule.

Now for the cool stuff!

17.5hrs/wk over 9 weeks is 157.5 hours total spent on the robot!

By actually saving more hours a week and allowing us to spread the time out further, we have actually prevented burn out, AND spent more time on the robot.

Morale of the story: By removing SBD, it does not require you to work your same schedule for longer weeks. It allows you to better manage your time spent on the robot, prevent burnout, and potentially create a better machine.

Re: [FIRST EMAIL] Stop Build Day Survey
 

I will give you an example using my team's numbers:

My team has about 120 students. During the build season, they're required to meet 3 hours per day, every day, after school to be considered on the team. Keeping all students occupied and out of trouble is a huge undertaking in itself.

After stop build day, there are about 20 dedicated students that will continue to meet or work on robotics, but the work is infrequent and not mandatory for everyone.

If stop build day is removed and our build season is extended, I doubt we'd keep a "team-only" stop build date. Our build season would be extended just like everyone else's, and that would significantly increase the amount of work - 300 student hours / day. Those 300 hours could be spent on schoolwork, athletics, jobs, other activities.

Not to mention, the school's coach of the robotics team is compensated extra the same as an assistant cheerleader coach. If the build season is extended any longer, we would have a very hard time finding teachers to sponsor the team.

Other than the size of my robotics team, I don't think my team is unique in how it would treat no stop build date.

Re: [FIRST EMAIL] Stop Build Day Survey
 

This is one of my least favorite things from being a student to a mentor. As a student it's annoying to have the reason you want to be there cut off for no apparent reason. It is less fun and it never did anything for me. As a mentor it sucks that all this extra time I could spend doing more hands on teaching work is wasted right when the students are most engaged with the program.

The most effective time to teach is when we are building the robot. The most effective teaching tool I have gets locked when it is most effective.


Also since it's very contested...

The mentor burnout thing makes no sense to me in the context of pro vs anti bag.

Why not meet less often?

My anecdote:

We have 7 people who regularly help us with technical roles. 5 full time workers, one collage student (me), one retiree. None of us get burnt out because we spent X total hours working. We get bunt out if we spend long hours day after day taking up most of a week and don't get time for other things during said time frame. I could work on robots twice a week for months and never burn out but 5 to 6 days a week for two weeks is really hard.

The only thing we actually need is consistent commitment from key mentors. The bag day is what forces that to be 2-4 days a week then 5-6 when something inevitably goes wrong in the late game. Why can't we just spread out our work the way that works best for our team? Why can't you just set your own schedule, stick to it so you don't burn out, and let us do what makes us more sustainable?

Stuffing all the work in to a shorter time frame is worse for burnout and hurts our team.

EDIT:
Thank you.

Re: [FIRST EMAIL] Stop Build Day Survey
 

Why, though? It's not as if, even in the absence of the resources to build a second robot, there's a dearth of things to work on between bag day and competition. Your team is already making a choice to arbitrarily cease work on a certain date - why would the removal of the bag requirement force you to change that policy?

Re: mentor burnout, the worst burnout I've ever experienced was scrambling in 2014 to build a practice bot from scratch over spring break so that we could test our code on an actual robot, which we had not been able to do before bag day. (In addition to costing me my mental and physical health, this cost several team parents quite a bit of money out-of-pocket). This would not have happened in the absence of bag day. So, the notion that removing bag day would help me, as a mentor, to not burn out is flatly inconsistent with my experience.

Re: [FIRST EMAIL] Stop Build Day Survey
 

Can you understand the difference between FIRST telling a student they must stop working on their robot on a certain day and a mentor telling a student they must stop working on their robot on a certain day?

The perspective is, "I think that rule is stupid!" versus, "I think that mentor is mean!"


Robotics and sports practice do not mix. Robotics and after school jobs do not mix. Robotics and after school activities do not mix. Any day spent after school on robotics is a day that can't be used elsewhere, and increasing the number of days spent on robotics decreases the number of days spent doing other things.

That will cause burnout.

Re: [FIRST EMAIL] Stop Build Day Survey
 

FIRST doesn't tell students that they must stop working on a certain day, they tell students that the robot must be placed in a bag on a certain day. The two are extremely different, and almost all of the students I've ever worked with have felt the same.

Re: [FIRST EMAIL] Stop Build Day Survey
 

Just saying that you have more than 6 weeks for build, and it's easier to explain to people that we get 6 weeks, rather than 45.5 days. It's 3.5 days that you are saying make not a 6 week season, but when rounded to the nearest week, it is in fact 6 weeks.


EDIT: Realized that I was only on page 11 of 16....why is this so long?

Re: [FIRST EMAIL] Stop Build Day Survey
 

Okay! Cool!

Lets do some more anecdotal math using the same starting numbers.

5hrs/day, 5days/wk, 6 weeks = 150 hours

4.5hrs/day, 4days/wk, 9 weeks = 162 hours

We have cut a little bit of time each day, and an entire day each week! AND WE HAVE SPENT MORE HOURS ON OUR ROBOT! :ahh: