|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#91
|
||||
|
||||
|
Re: paper: Stop the Stop Build
Quote:
After doing this for the past 4 years, Code Orange has done the "7 days a week." We are moving to 4 days a week too. We think this will help our students have more time to stay focused on school and keep the meetings more fun. I noticed a lot of top teams are making this switch. |
|
#92
|
|||||
|
|||||
|
Re: paper: Stop the Stop Build
Quote:
--More often over shorter time, or less often over longer time? (Assumes the same number of meetings, or very close.) --More meetings over more time, or same meetings over same time? (Assumes that teams maintain current schedule and simply move crunch time later.) I would suspect that the disconnect is this: Teams that want to keep the bag are likely to assume that the SECOND part is the key. Teams that want to ditch the bag are likely to assume the FIRST part is the key. Basically, number of meetings vs time available to have 'em. Quote:
|
|
#93
|
||||
|
||||
|
Re: paper: Stop the Stop Build
Quote:
- More time available will drive more time to meet increasing total commitment. - Open build allows all teams to continue iterating. You will need to do the same to remain competitive. - Open build will provide more opportunities for design convergence. Either way you look at it, FRC is a huge time commitment. Change is never easy. Fear of the unknown is common. I've reflected on this debate and how it would impact me. Commitment to this program is a personal decision. In my case, it would probably drive some extra meeting time to iterate. But oddly, I believe it would reduce my stress. I'd rather spend my time improving, repairing, and practicing with one robot than trying to maintain two. David |
|
#94
|
|||||
|
|||||
|
Re: paper: Stop the Stop Build
Where did I make this argument? I do not think this, and did not say this.
Quote:
I expected neither "Have-you-tried-not-making-mentors-burn-out" nor "I-find-it's-preferable-not-to-burn-out-if-you-can-help-it" to be particularly novel ideas that this team had never thought of. Rather, I had hoped to foster a reply to understand why these might not be on the table, even with an extended build season. I want to better understand differing viewpoints on this and (in particular) what attitudes would be towards some sort of middle ground. |
|
#95
|
||||
|
||||
|
Re: paper: Stop the Stop Build
Quote:
Edit: And good point at the end. I wonder how many more people in a similar situation would be saved the stress. 1 - More time available will drive more time to meet increasing total commitment. This can be solved by simply committing to a set amount of involvement before the season and sticking to it, which a lot of us do already. It's a problem created or subverted by personal choice and that won't change without the bag. 2 - Open build allows all teams to continue iterating. You will need to do the same to remain competitive. Great! More time for learning with the robot. And if you don't want that... You could decide that whatever level you can obtain by meeting on a bag&tag like schedule is good enough for you. I know that doesn't sound great but people often debate the overall importance of on field performance, and any given team can decide that for themselves. You can also back load your build meetings to see what is working and what isn't before you start finalizing things. 3- Open build will provide more opportunities for design convergence. I don't see a major problem with this in the first place even if it turned out to be common, and it wouldn't be common. There are few teams that can competently pull off major copies of robots. They would need to be very well organized and disciplined to basically start their whole process in week 5 or later just to build a verbatim copy of another robot. They would probably end up with just as good a robot if they came up with their own ideas. The other scenario that a team would pull a complete remake ignores the fact that a team capable of such a feat would probably not need to copy anyone. Any more minor design convergence seems either unimportant and virtually unavoidable anyway. There are only so many effective ways to accomplish a given task in FRC with the current hardware constraints. Most teams are going to be more concerned with doing what they are most comfortable with rather than attempting to copy someone. |
|
#96
|
||||
|
||||
|
Re: paper: Stop the Stop Build
Actually, this finally went to FIRST official and around the world. They have the survey online now, discussing the pros and cons of Stop Build Day. I honestly don't think that they will get rid of it, nor do I think that they should, but they might be extending it another week or two, which could be a hail mary for a lot of teams.
|
|
#97
|
||||
|
||||
|
Re: paper: Stop the Stop Build
Did FIRST say they are considering this specifically?
|
|
#98
|
||||
|
||||
|
Re: paper: Stop the Stop Build
Quote:
|
|
#99
|
|||||
|
|||||
|
Re: paper: Stop the Stop Build
Quote:
|
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|