I think this basically sums up the whole thread. Any learning can be boiled down to copying if you twist it right. I think with time people will receive more transparency on the RECFs definition of “copying” as real time examples play out.
Probably goes without saying, but will say it anyway.
I expect many minor (and maybe a major here and there) updates to G4/G5/SCP over the next year or two to help clarify intent, resolve outlier scenarios, round out examples, etc. as more questions arise, situations present themselves, etc.
We (VEX & RECF) are following this discussion (and discussions happening elsewhere) to take note of questions, comments, concerns, etc. and will continue to work to answer them as best we can. The first round of Q&A follow-ups to the G4/G5 update should roll out tomorrow.
Here is another part of the equation that needs explained or revamped as well with this updated process. Any complaints filed online after an event, the ability to challenge/protest the violation is a joke. We had a G-something complaint against our team last year and we get the basic email stating the violation and then provide as much information. Well, we did and then two weeks later you can tell we got the auto reply of you’re guilty. I had to email three more times to try and get a call scheduled to fight this before I got someone to respond and for them to drop the complaint. Other people I talk to tell me they get the same auto response of you’re guilty when they always aren’t. RECF is going to need to hire a full-time employee to legitimately review these.
Again, great changes that will take time to flush things out, but the review/appeal process needs reworked and the process should be transparent to us users.
I also wouldn’t mind a generic reporting per region that tells us the monthly violations, to see if certain regions are really applying this enforcement. Again, transparency is a win-win for everyone.
I think it would be fairer if, when a complaint is filed, the head referee reviews the team’s engineering notebook and interviews the students before deciding whether the team has violated the rules.
I think the current language is ineffective. If VEX could disqualify teams that submit false reports from future event, it would make the competition fairer. Both teams involved should face consequences.
Why the head ref? Why not the EP and/or the Judge Advisor? Why omit the RSM, who might at least have some context across regional competitions?
Did you look at the RECF submission form image I posted? The form talks about potential consequences for filing a claim in bad faith.
You seem to imply there’s a binary choice - either the team is guilty and is punished, or the team (and it need not be a team raising suspicions about a team) submitting the claim is guilty of submitting a false claim. There is room for there to be legitimate suspicion that is not actually a violation.
I only suggested having the head referee involved, but it could certainly be another person. I reviewed the language you mentioned, and I don’t think it clearly defines any consequences. As it stands, it doesn’t really have any impact. How do you plan to actually implement this, or is it just meant as a warning? People understand what “suspicious” means—I could easily claim suspicion about the previous world champion’s work and report it.
It says “…submitting false, misleading, or inappropriate information is considered a misuse of this for…may result in a Code of Conduct violation being filed against the reporter”.
I don’t know how much more clearly they can spell out “consequences” for abusing the process.
TL;DR - Teams should avoid anything that comes close to “copying” other robots and teams should avoid making false accusations of “copying”, both activities could result in Code of Conduct violations resulting in a variety of consequences based on severity, up to, and including removal from participation in RECF/Vex competitions.
The issue lies with the word “suspect.” Under the current rules, as long as someone has a suspicion, they can make a valid statement. There will not be any consequence since they truly believe what they believe is true. . However, “suspect” is based on personal feeling, not on actual evidence. I recommend changing “suspect” to “have evidence” so that claims must be supported by proof rather than subjective impressions.
@bkahl you were not kidding when you said the Q&A today will amplify things - in particular for coding and use of libraries:
I urge forum members to wait an hour or two before reacting. It is huge clarification. I hope Middle School teams really dive deep into this last statement:
Teams that utilize example code or custom libraries from outside sources should use caution. The program used should represent the students’ efforts and abilities. Blindly using code without understanding the code functionality is not consistent with the educational goals of this program. Students should be able to understand and explain the code, and students should be able to demonstrate that they can program on a level equivalent to the code used in their mechanism.
In my experience, this has been problematic for a number of seasons and clearly addressed in the G4 update and this Q&A for coding.
I suspect that you may not coming at this discussion from a place of “good faith”.
If its makes you feel better argue with the RECF about the word choice, take it up with them. What leads you to believe that the RECF investigation of submissions with no credible evidence would not be punished under the current wording? It’s not in the RECF’s interests to get spammed with garbage reports. Their way to disincentivize that is to punish people submitting garbage reports.
From what I understand, a problem remains. The code in the libraries I have looked at, like the code in codeV5 is in a black box. A novice team using codeV5 to implement a drivetrain object and use a driveFor command has no idea what that code actually looks like, only what it does and what parameters it allows. Similarly a team using an advanced library will not be able to see the code behind driveToPoint to either learn how it works or confirm they could write it themselves.
There are a number of PROS libraries that are opensource. For example, LemLib is a popular one, and is opensource. Students can ready the driveToPoint function on GitHub. Students can even make changes to the implementation.
This will make for a very exciting season, I’m looking forward to seeing how this all shakes out. Will there be a quick question list of what to ask people about PROS? Will describe how the VIQ Drive component work?
Free advice is always worth what you pay for it, my free advice would have been just do the physical robot this year, software another. But ripping the duct-tape off is also another approach.
I guess at this point “I welcome my new G4/G5 overlords”.
I’m pretty sure teams are allowed to use any VEX created libraries/code such as the drivetrain class you mentioned. I don’t believe it is a problem if they don’t understand this, similar to the herobot, as it is used as a staring point for teams. If beginner teams were expected to be able to code the drivetrain or motor functions in VexCode, they would not be able to, leaving many teams just without code.
What IS a problem is using an outside made template/concept without understanding like the JAR template’s Chassis class. Also the only template I have seen where you can’t find the implementation is VEX’s, not sure what others you are referring to.
