Adding on top of what you said, I propose that instead of defining behaviors with colors, we would use a scale from 0 to 10. 1 being least desirable and 10 being most desirable. 0 is flat out illegal.
As @technik3k stated, there is no clearly defined lines, and the same situation can be legal and illegal depending on the context.
I think one of technikās main points was that creating an āillegalā state allows the creation of loopholes and fosters rule ābreakingā. One (albeit extreme) analogy of this might be decriminalization vs. criminalization of drugs and the formative results of the decriminalization of drugs.
Personally, I feel that this, having a formally written āguidelineā rather than a set of explicit rules (not to say that the punishments for these things should be removed, it doesnāt completely parallel drug laws, of course), is far more productive. It introduces a new source for parents and mentors who arenāt just competing vicariously through their kids/students, but rather are too involved because they donāt know a better method of educating those kids and students. Giving them this guideline makes a clear pathway to what is known as an effective way to approach STEM Education. Having as few as possible, but still enough to convey the levels categories is particularly effective because it reduces the āgray areaā type of issues but also makes it a lot easier to actually create rules. I would rather have many, many categories than have 10 levels for a few categories.
Really great discussions and right direction by RECF. However, I canāt seem to get over the green/yellow/red designations. Maybe itās just mainly the yellow sections. Green and red sections seem pretty straight forward. By making this āthis is ok, this is not ok, etc.ā we are trying to define what can or canāt be done, and there lies the problem. Thereās lots of grey area, and a lot of it is subjective and situational.
Kids arenāt born already with all the know how in robotics, engineering, programming etc. They mostly have to be taught. Take for example, in the document a lot of green and yellow for programming centers around adults teaching basic programming concepts. Fundaments are things like loops, conditional statements, syntax. What about more complex concepts such as multi-tasking, PIDs, etc.? With our IQ team this past season I taught them the concept of PID. We spent 2 whole months on what they are, learning about self driving cars, bang-bang control, white boarding what is proportional, integral, derivative, putting those onto a cartesian plane so they could really understand things. All before even getting into pseudo code. By the time they understood PIDs, it took them about a couple of hours to write the code.
I do like the suggestions that technik3k mentioned. Maybe we should have a progress chart with examples of what an idea team/organization should be (student lead).
In regards to the green/yellow/red, I propose a different approach that links this to other aspects of VEX. Use the descriptors that are used in the Judges Rubrics - Expert, Proficient and Emerging to describing coaching behaviors and practices. The underlying assumption would be that coaching practices and behavior are expected to improve with experience, just like students are.
Donāt know if this is already a thing, but if it is I havenāt found it, would anyone be interested in helping me put together a google document for vex newbies? It would have a single page sorted into a bunch of different subjects that would have a link to a google slides about that subject that would contain advice and links to videos and resources already existent on that subject
EDIT: Perhaps I should start a new thread on this
https://www.vexwiki.org/start
A lot of past efforts that have come and gone. VEX had a wiki, but that was taken offline. VEXwiki.org has been around for a while, just needs traction. BNS had a site, but it went away. The hard part is sustaining an effort like this. A good idea, but requires a lot of work.
ManiacMechanic had the greatest guides for both roboteers and mentors. Reach out to her and use that as a start
Just stumbled upon an updated version of this document on the new RECF website:
https://www.roboticseducation.org/documents/2019/08/student-centered-policy-rec-foundation.pdf/
Thanks for finding this. Once again, I think this is a great step in the right direction, and Iād like to thank the REC Foundation team for their efforts in this area. Iād especially like to draw attention to the clarification about alliance seletion and related strategy, and the addition of sections going into detail about programming and citations. This creates a good foundation for expectations, especially surrounding judged awards, while promoting the existing culture of sharing of knowledge and ideas.
One topic that I think is still ambiguous is the status of features included in programming environments. Iāve asked a Q&A question to clarify. I also asked about the enforcement, as I found that section to be vague, and I see potential issues relating to the section on team attendance, especially for relatively large teams such as my own.
For anyone who is interested, hereās a list of things I could find that were changed from the original public draft:
- Formatting improvements throughout
- Removed from first paragraph of Using the Guide: āThis guide does not encompass every possible scenario that may arise at an event or in an outside learning environment, so participants will need to refer to the spirit of these examples to help interpret situations not explicitly covered.ā
- Added to the definition of Adult: āStudents in advanced programs that are mentoring younger students would be considered āmentorsā in this case (ex: HS VRC student mentoring a VIQC team).ā
- Definition of Event changed from āCompetitions that are posted on Robot Events and fall under the REC Foundation jurisdiction.ā to ā: Tournament or League competitions that are official REC Foundation qualifying events or under the jurisdiction of the REC Foundation, including VEX Worlds.ā
- In Interpreting the Guide, changed āThe columns are color coded to help communicate the goals for increased student-centered learning and to share behaviors that are not aligned with our mission.ā to āThe columns are color coded to help communicate the goals for increased student-centered learning (āgreenā and āyellowā) and to share behaviors that are not aligned with our mission (āredā). Many of the described behaviors will overlap between the āgreenā and āyellowā columns to allow flexibility with providing appropriate support for students.ā (emphasis present in original)
- Indicate column position in the explanation of green, yellow and red
- Remove references to ānoviceā students in yellow column
- Add to red column for game strategy at events: āAdults specifying teams to select for alliance selection (VRC) without student collaboration.ā
- Change yellow column for programming at events from āAdults demonstrating a programming feature or sharing new programming knowledge to novice students. Students are programming the robot during and after the demonstration.ā to āAdults describing 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.ā - In green column for pit interviews at events, change āStudents can describe how their robot was designed, built, and how their program code functions.ā to āStudents can describe in detail the
development of the:
⢠Robot design across the season and
functionality of the mechanisms
created.
⢠Functionality of the program(s) utilized
on the robot being used at the event.ā - In green column for programming outside of events, change āAdults teaching students basic programming techniques or pseudocode that students can modify and apply to their robot. Programming concepts or tools leveraged from other sources should be credited in the code as comments and in the engineering notebook.ā to āStudents learning programming fundamentals from Adults or other sources that can be applied to create custom programs for their robots. Students crediting how programming concepts were derived as comments in their code and in their engineering notebook.ā
- Change yellow column for programming outside of events from ā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.ā to āAdults collaborating with students on developing their program flow using pseudocode, flowchart or other visual representation. Students using the preinstalled driver programs.ā
- in red column for programming outside of events, change āAdults programming the robot (driver or autonomous) or providing custom code to copy/paste into a program.ā to āAdults programming the robot (driver or autonomous). Students copying/pasting all or portions of custom code developed by Adults or other sources.ā
- Add the āFurther Notes on Programmingā and āCitationā sections