What are you doing right now?
I expect James Pearman code to be allowed for use given the way he presents it as examples of how to accomplish specific functions, properly documented and explained. It is up to the team to figure out if it is relevant to their problem, learn how to use it, and document how they used in their engineering notebook as part of their design process. If the team fails to be able explain the use of his code in their solution, that would be a problem. If an adult on that team points out to the team there is this useful code example that could help the team solve its problem and they go ahead and use it, can explain it, and document it, that would be probably ok in the new policy as I read it. If the adult goes and folds in the example code without explain to the students what is really going on, and/or the students can not explain the use of the demonstration code, that is not ok under the new policy.
I think the key is for the students to be able to explain and document the use of demonstration code in their solution. I use James as an example 1) the quality of his examples and explanations are exemplary, and 2) the examples are demonstrations of how to approach problems not specific to the game being played or a particular robot.
There are many examples out there which are used by many teams - some well understood and documented by the students, others not so much.
Again, I think the new policy is a solid start about adult involvement on teams.
For communication outside the standard scope of competing, sure. Any dispute between a team and an event staff member should definitely have an adult from the teamās side involved, even if only as a witness. But for most of the day to day things, i think it takes away a lot.
Students should be able to speak to the referee without their teacher/parent/mentor/coach standing over their shoulder.
A specific instance i had a problem with was signing in at the US Open. Our students were told they could not sign in without an adult. They could not pick up their sign in packets without an adult. And while the students were supposed to be getting themselves signed in, the adults were busy carrying stuff in from the car to their pit area.
This was extra annoying because the entire senior team was over 18.
My response was probably a bit less polite than it should have been. I let them give me the clip board, then handed it to one of the students to sign.
I understand having a legal protection against accusations, but having your adult volunteers in pairs, and especially out in the open, i think you take away far more agency from the students than is really merited or acceptable within the realm of āstudent centeredā.
Requiring an adult from the team when taking students behind closed doors for an interview or when meeting with them one on one in their pit area or at the field is reasonable. Forcing them to get out of line, hunt down their mentors, drag them across the building, just so that you can hand paperwork to someone you consider more responsible is not.
The world vastly changed with what happened at Penn State and was brought to light in 2011, and with issues with the Catholic Church.
Prior to then kids could do lots of things. Now the rules are adults that need to interact with a minor need to have a second adult present. For people in scouting this has been a long term policy. Itās a pain, but we deal with it. Background checks are now the normal. If you want to chaperone a trip with your kids and other kids, you need the background check.
@Robo_Eng_13 I feel your pain, but itās hard to tell at a glance who is over 18 and who is not. I would have had the roboteers carry things in and just gotten the packets and signed for them and called it a day.
Itās a case of a very small subset of people doing really awful things that ruin it for the rest of us. Or as I say āPeople are why we canāt have nice thingsā.
What happened at penn state in 2011? And what issues were there with the catholic church?
It seems very clear to me from reading the attached document that āstudent centeredā refers to the design, implementation, and operation of the robot. It does not appear to apply in any way to the administration functions of the team, which include things like communicating with RECF, communicating with EPs, filling out forms, etc.
I really do not think RECF is trying to encourage teams that are āstudent onlyā, i.e. students doing all the robot stuff and also all the administration stuff. In fact, I would suspect that the RECF would discourage that.
If my assumption here is correct, then perhaps it would be a good idea to add some wording to that effect to the document in question here.
That may fall under the category of RECFās goals not always being perfectly aligned with Mentorās goals. For us, by the time a team is in their senior year, we want them to be able to handle basically everything but the check book, and even then to some extent they can be given a budget and allowed to plan out what materials they want to buy vs what they want to improvise with what we already have.
Part of our goal as mentors is to have our students leave high school with as much preparation for college, career, and adult life as possible. That is not RECFās goal, so they arenāt really under any obligation to go out of their way to facilitate that, but anything that directly hinders that should be avoided if at all possible. Again, having an adult witness any time an adult is meeting with a student independently is absolutely necessary and makes sense. When there is a table of 6 volunteers doing check in, and lines of adults and students signing in, it seems like an unnecessary hindrance to require an adult to sign the students in.
Ask your parents to talk to you about it.
Editted: Iām not saying this in a snarky way - but the discussion about this is better with your parents, not internet strangers.
Iām going to quote Dave directly:
Daveās understanding is correct.
The purpose of the document the RECF has posted for public review to help define what is acceptable parental / coach involvement in designing / building a robot and at competitions.
The REC Foundation policy requiring students to include their parents in communications to the RECF has nothing to do with treating students with respect and everything to do with protecting both the student and the REC Foundation. Students can still present to judges without parents in the room. Students still appeal calls directly to referees. Yes, we now require an adult to be at the check in because we had at least two instances last season where there was a medical emergency with a student and there was no coach / parent for that team present. In both these instances, there was at least one student of driving age that drove the team to the event and no coaches / guardians attended. The RECF can not act as a guardian in this situation and make medical decisions. We do have an obligation to legally protect ourselves, the EPs and the event facility. I really do hope that the community understands this.
Absolutely spot on! In the larger picture, EPs are protecting the students by assuring they have the safest environment for competition.
I am pretty sure every EP has a situation that gave them pause - my events were typically have an senior administrator, Principal, Assistant, and even Superintendent, on site during the event and there have been medical, and other issues where they stepped up. We also have Police detail for large crowd control, although the officers usually say it is the easiest details they ever had to do and interestingā¦
So Dave is right, decouple team autonomy at an event from institutional/legal responsibility in the policy statement.
Do you mind if I ask. If you canāt email a student directly how you plan to have meetings with students as part of the advisory board?
He can email the student and copy the coach. When the kids applied, they had to provide team info.
Letās be constructive about the discussions here. As an EP, Coach, and educator (hats I wear), I want this document to be best as possible. Given the breadth of people in the program, there will be disagreements.
I urge students on teams to discuss with their teams, including adults that represent the organization. Then post recommendations on how to improve this document for Student-Centered parameters in competition.
Firstly, Dan and Lisa, thank you for putting this together. I agree with the other respondents that this is a great step in the right direction for the RECF and the VEX community. In particular, I want to thank you for putting this out for review by the community; it means a lot to us that we have the opportunity to provide constructive feedback at this stage. I know my response is unnecessarily long comprehensive, and please excuse my pedantism in a few places, but I wish to make sure that this document is as clear and useful it can be for the community.
Format
I second the comments from @Foster and @sankeydd regarding colour - maybe do pale colours, and green, blue, red? It should be printer-friendly (and ink-supply-friendly), which also ensuring the colours have the intended connotations.
Team Leadership
While I understand @tabor473ās comments regarding team leadership, I also understand the legal realities and that the RECF canāt budge there. I donāt think thereās any fundamental disagreement in intentions here. While it has been made clear that team management and leadership is beyond the scope of this document, it would be nice to see an endorsement of providing students with leadership and project management experience through robotics wherever possible, either here or elsewhere. I believe this could reconcile the RECFās communications and liability requirements with concerns such as Taborās.
Overall Comments for Technical Sections
I think the document makes a good start of laying out expectations for teams and adults. However, there are a couple patterns that I see across multiple technical sections that I think could be improved.
To start, there are a few places where the yellow column describes adults teaching students fundamental principles and skills, and the green column describes students mostly brainstorming solutions from scratch, with some educational contribution from adults. Iād like to suggest specifically endorsing student-to-student teaching of ideas and skills wherever applicable, as this tends to be a hallmark of a repeatedly successful team, and demonstrates responsibility, maturity and independence on the part of the students.
More generally, a different way to approach this would be to make the green column represent an ideal to strive for, consisting of absolutely no adult contribution (outside of legal requirements of course). The yellow column would still describe acceptable adult support for novice teams and students, and the red column would still describe unacceptable adult involvement. This would avoid ambiguity and overlap between the yellow and green columns.
Game Strategy
I was particularly surprised to not see a comment here regarding alliance selection. In every organization that Iāve been a part of, every strategy decision, including alliance selection, is the perogative of the students themselves. However, Iām well aware that this isnāt the reality everywhere; I have seen many cases of adult coaches dictating alliance picks for their team. I would expect this to be against the spirit of the competition regarding student involvement, however the comments on at-event game strategy are too specific to cover it as-is. For example, the red column reads:
Adults giving students on their team or alliance partners step-by-step match play instructions prior to or during a match.
If my understanding of the RECFās intentions is correct, Iād suggest adding a sentence to each column stipulating that, while adults may provide guidance and suggestion where needed and applicable, strategy decisions should be up to the student members of the team.
Mechanical Design
In addition to the general comments above, Iād like to comment on the last sentence of the green column for the outside-of-events mechanical section:
Design ideas leveraged from other teams or videos should be credited in their engineering notebook and during Pit Interviews.
While I entirely agree with requiring teams to attribute ideas to their creators, I think there are a few key scenarios that are overlooked by this clause:
- Why is there a requirement for crediting ideas from other teams, but not ideas from your coach(es)? There is a wide variety of experience among coaches, and in many cases students may learn about key design principles (such as uses of different types of nuts, or concepts such as the 4-bar linkage). I donāt see a reason why this should be treated any differently than teams who are able to learn this from their coach.
- Most design concepts, even if they appear specialized at first, are useful beyond a single season. How would teams be expected to attribute concepts in this scenario?
- There was a time when the double-reverse 4-bar was a novel idea in VEX. For the past few years, it has been effectively ubiquitous. At what point does a concept become ubiquitous enough that teams would no longer be required to cite an original source? (This is closely related to the first point).
Programming
I have some specific feedback regarding the āProgrammingā clauses in the guide. For āAt Eventsā, the yellow section reads:
Adults demonstrating a programming feature or sharing new programming knowledge to novice students. Students are programming the robot during and after the demonstration.
I think this needs to be reworded. Hereās a suggested alternative:
Adults suggesting high-level programming concepts and debugging techniques that may be useful for solving an issue that the team has encountered. Students devising and making any necessary code changes.
The reason Iād suggest this change is that most programming activity at competition does not fit in the lesson-and-apply format that the current wording seems to imply; rather, teams are often trying to scramble together a hotfix before the next match, and clarifying what role adults can play in this process would be beneficial.
Now, regarding the āOutside the Eventsā programming section. As others have mentioned, there is a lot more nuance in this area than the document reflects. Iād like to point out a few potential issues that I see.
Firstly, the yellow column as written appears to discourage members of experienced teams from taking computer science classes:
Adults teaching general programming fundamentals that can be uses as tools for students to create custom programs for their robots. Students using the pre-installed driver programs is allowed.
The first sentence in particular seems to describe any form of external help or educational resources at all, which I donāt believe is the RECFās intention. Moreover, this seems to significantly overlap with the green column, in particular this sentence:
Adults teaching students basic programming techniques or pseudocode that students can modify and apply to their robot.
I also find it surprising that teaching programming fundamentals should be reserved for novice teams, but providing pseudocode is acceptable for experienced teams. Iād argue that āpseudocodeā is extremely ambiguous in this case; it could mean anything from a certain method of teaching computer science concepts (hopefully acceptable?), to adult dictation of autonomous strategy (clearly disallowed). Perhaps participation in educational opportunities (formal or otherwise) for relevant computer science principles and skills should be described in the green column, while the yellow column should describe a case of adult-guided brainstorming and planning in which the students are still able to contribue to the design and are solely responsible for implementing it.
Secondly, the guidelines as written appear to prohibit the use of many key features of the V5 platform and programming environments. For example, part of the red column reads:
Students are utilizing programming techniques that are beyond their ability to explain or create independently.
I believe that the intention of this sentence is to say that students must be able to explain the code taht they wrote. However, it could easily be interpreted as requiring a complete understanding of PID in order to use the built-in velocity and position control in the V5 and IQ motors, for example, or a complete understanding of time-slicing and RTOS fundamentals in order to use the supplied multithreading facilities. Iām honestly not sure if this is the intention or not, nor where the line should be drawn; I could understand an argument, that, for example, in order to be able to write and understand multithreaded code, one must have a concrete grasp of time-slicing and other concurrency fundamentals. However, I wouldnāt necessarily expect such students to be able to write a scheduler from scratch.
This gets even more confusing when we discuss open-source code. Here are several different examples to illustrate this complexity:
- PROS is an officially endorsed programming environment for the V5. Does this mean that any code submitted to and accepted by the repository maintainers is allowed to be used by any team? What about custom forks of PROS, or development-branch features not yet merged into master?
- OkapiLib is library included with PROS which facilitates various aspects of programming, such as motion control. It provides features such as chassis controllers which implement some common abstractions, such as a PID controller for a robot drive subsystem. As OkapiLib is included with PROS, would its abstractions be automatically considered part of the platform, thus permitting any student to use them, or would a student need to demonstrate understanding of PID and other controls engineering concepts?
- bV5 is an unsactioned alternative programming platform for V5 put together by a single developer in their spare time. Does its unsactioned status mean that no student is allowed to use it? Would students be allowed to use it assuming feature parity with PROS and other more āofficialā platforms? Would there be some other restriction relating to its purpose as a programming platform? (A cortex-era equivalent would be James Pearmanās ConVEX platform, or PROS at the time.)
- Earlier this summer, I open-sourced our (team 5225Aās) code from the In The Zone season. This code is written in ROBOTC for the now-legacy Cortex platform, however that doesnāt make it entirely obsolete. Would a team using the Cortex platform be permitted to use some of it on their robot? Would teams using V5 be permitted to re-implement the same algorithms, derived from that code, on a V5 programming platform? Would any of this be contingent on the students fully understanding the algorithms (for many of which we havenāt explained our thought process or how we arrived at that math), despite them having no input at the design stage? What about derivative works of these algorithms, or anything inspired by code seen elsewhere?
- Do any of these scenarios depend on the age of the person who wrote the open-source library? What does this mean for the majority of open-source projects which have multiple contributors, or for projects which were started when the author was a VRC competitior, and they continue to develop it as an adult or VEX U competitor? Separately, is a distinction made between members of VRC teams, members of VEX U teams, and other adults form a VRC point of view? There are also some parallels to CAD libraries that are shared by studentsāthough these still obviously require the students to build the robot themselves.
The reason why I bring all this up is, akin to Fosterās points about the yellow column, it is important the RECF is very clear about its intentions and expected results, to avoid inadvertantly condemning perfectly reasonable behaviour. It would also be nice to take advantage of this opportunity to clarify the RECFās stance on these nuances, and to provide guidelines for how teams should approach the relatively new prevalence of open-source projects in the VEX community. Obviously I am being a bit pedantic in my interpretation of the document, but I think to be most effective it needs to be as clear and unambiguous as possible.
In addtion, any source code released publicly is generally released under an open source license. Understanding these types of software licenses and their corresponding rules and restrictions is important for anyone who uses them (which, nowadays, is virtually every programmer, across industries). This might be a good place to encourage students to educate themselves about software licenses, and to stipulate that they follow them wherever applicable.
Pit Interview Preparation
I agree with this section in general; however, I see a potential ambiguity between this sentence from the green column:
Students practicing mock pit interviews and getting feedback from adults and other students.
and the contents of the yellow column:
Adults and students working together to practice talking about their robot design process.
To me, the yellow column could be easily interpreted as a less-specific version of the green column. If the intent here is to describe adults actively contributing to a plan for the interview, then this appears to overlap with the red column:
Adults giving students scripts or step-by-step instructions of what to say in their pit interview.
This goes back to the general feedback of needing more clear distinctions between the green and yellow columns. Personally, I donāt think experienced teams should require adult support at all for preparing for interviews; students should be able to provide adequate feedback to each other on their own. However, adult support should of course be permitted under the yellow column, as not every team will have this level of experience from the get-go.
Once again, I want to thank the RECF team for taking this on, and I hope that this document becomes a useful and applicable resource for students and coaches alike in the seasons to come.
he is talking with a student directly right now.
Any student selected to the SAB that is under 18 will be required to have their parent / guardian sign a consent form that they are able to participate on the calls and receive emails from the RECF SAB team.
Thanks,
Dan
I have one observation re: Student and Adult definitions. In a large organization that encompasses all levels of VIQC and VRC, (e.g. a K-12 school) a high school senior student could be provide help to a middle school VRC Team or a VIQC Team. I think a note somewhere calling out that older students should be looked at as adults in those situations, if that is the intention.
Letās try to avoid naming names and pointing fingers here; the point of the thread is to provide feedback on this policy document, not to call out specific teams for doing something you disagree with.
Ultimately, adults are in charge and that is the way organizations need to be. As a leader of a BSA Scout troop we regularly put youth in charge and that is our model. The goal of the leader is to watch all activity passively.
But⦠we also have strict youth protection requirements. There are strict rules prohibiting one on one interaction between adults and youth (excluding our children).
Notice that Dan didnāt say the conversation had to start with the adult. Just that it needs to include an adult. Keeping a coach or parent in the conversation is protection for both the youth and adult.
I didnāt notice anything I didnāt like the first read through. Looking at the comments, I would like to mention Iād always approve of students being able to run their entire team, but you seem to have good enough reasons.
I did find a typo in the yellow section of Programming: āAdults teaching general programming fundamentals that can be uses as tools for students to create custom programs for their robots.ā The āusesā should be āusedā
I didnāt check all the replies, but hope this hasnāt been said already