I’m curious about who you think interprets the word “available” in the context of the rules at a competition? What if two teams disagree about the meaning of that word?
Final say goes to the LRI at a competition. If two teams disagree about the meaning of a word, look it up. I would be surprised if anyone tried to refute a dictionary.
“But the designs were available publicly…”
“Available publicly? I eventually had to go down to the cellar to find them.”
“That’s the display department.”
“With a flashlight.”
“Ah, well, the lights had probably gone.”
“So had the stairs.”
“But look, you found the code, didn’t you?”
“Yes,” said Arthur, “yes I did. It was publicly available in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”
If you are looking for a definitive answer, the way to do that is by proving the English word “available” has a single technical meaning in this context. I believe this is hard, based on your screenshot:
Why circle definition 2, but not definition 1?
I propose your screenshot is an example where, in a technical context, “available” is ambiguous.
Furthermore:
Ambiguity is important to take into account, well before you get to competition. Ambiguity leads to different LRI’s making different decisions on whether a robot gets to compete or not. Due to the cost outlay in building a robot and bringing it to competition, the ability to compete is an important topic.
I sent Steve a PM on this, but I had misinterpreted his initial post. I am in agreement with him: If teams want to ensure they’re “OK”, posting in a public form is the right idea.
In addition: Clarifying the exact criteria which are to be used at inspection time will reduce ambiguity, which helps reduce unneeded work and risk of non-competition.
As I already alluded to this is not trivial to accomplish. However, difficulty to accomplish it is not an excuse for ignoring it.
Allll this being said, a reality check: How many robots have been barred from competition for re-using non-public designs? Probably very few. Perhaps 0. This tells me the action item of “fix R14/R16” should be low-priority for the Game Design Committee - either everyone’s compliant as is, or nobody actually cares (except a few of us here on CD).
However, it doesn’t mean “not a priority”.
Another location, that hasn’t been updated as regularly as in the past sadly, is the firstwiki github. It had a nice system where you could add a repo to your team’s page and it would also add it to the consolidated code directory page. https://firstwiki.github.io/wiki/robot-code-directory
Almost every rule in the book has a fuzzy line. How closely you skirt that fuzzy line is up to you, with the understanding that the closer you get to the line, the more likely it is that you’ll have to defend your decision to someone. Having a public github with your code on it is probably fine. Having an unlabeled youtube channel where you verbally read your code off the screen probably isn’t.
Per the letter of the rule, the public github option is almost certainly okay. Also per the letter of the rule, the spirit of the rule is irrelevant.
As a (new) mentor, I think the best way I can contribute to the community is to point to good examples and gather useful information.
The kids and 18 year old seniors get to make awesome things from there.
Laughs in secret communications to refs and LRIs that significantly change rule interpretation without changing the verbiage of the rule
Though I don’t really see a way for them to pull one of those on the particular rule being discussed. Short of FIRST hosting everybody’s releases there’s bound to be plenty of loopholes.
Has anyone ever had a discussion with an inspector about the prerelease of their code or CAD prior to kickoff? I’m not sure I ever have with teams I was inspecting directly. I’ve discussed the theory and intent of the rule but never once have I thought to try to have a team remove code or take something off their robot for not meeting this rule. This rule is clearly only enforceable on the honor system. When you sign the paper at the end of inspection does your team feel like they have met the requirements of this rule and are competing fairly?
Isn’t posting code/CAD publicly supposed to be in the spirit of gracious professionalism?
I don’t have an issue with a team that is running barebones drive code not publicly posting their code but I do run into an issue if a team has a new and innovative idea that they refuse to share to gain a competitive edge. That’s not what FIRST is about
Thankfully I haven’t encountered this throughout the duration of time I have been involved with FIRST.
I get what you are saying about the definition being ambiguous, and in other cases it might be. In this case, the only other definition that makes sense is 1, which means pretty much the same thing. So, available is not ambiguous.
And this is the core of our disagreement - I believe “obtainable” and “ready for immediate use” have very, very different meanings when it comes to software.
Specific, non-FRC example: Linux Distributions - Arch Linux vs. Ubuntu as a desktop environment. Both are obtainable. Only one is “ready for immediate use”.
My mother is a wonderful, and very intelligent woman, though without a modern, formal software background. She would have no problem getting Ubuntu up and running on a computer if asked. But Arch, I wouldn’t wish upon her in 1000 years.
I’d also guess that our opposing takes on the same topic is heavily rooted in previous experience. The industry I work in isn’t known for sharing the nitty-gritty details of software functionality, so I tend to be pretty sensitive when folks insist they’ve made something “available”, but it’s still totally not usable at all.
I also like a good argument
Why are you comparing FRC robot software to an operating system?
Simply put, they are both open-source software, written by someone else.
More specifically, an end user has to interact with both in a similar way. Both involve taking source code or binaries created by someone else, manipulating and integrating them with new pieces of software or hardware, and creating a final device that has useful functionality.
Additionally, its an example I can speak to. I have set up both as desktop environments.
It’s very different because all FRC teams have the same build tools. When a team releases software, another team can easily build that software, so it is “ready for immediate use”. FRC software is only made for FRC teams, so it only needs to be “ready for immediate use” for them. Arch is made for everyone, and not everyone has immediate access to the necessary build tools.
Folks. Look at what is happening here.
There was no “linguistics debate” until Steve suggested we have one.
Before that, we were talking about whether it’s possible to acknowledge a rule as unclear despite some individual players having their own clear vision of GDC intent. It’s Round Bumper Syndrome.
Fair enough. I’m still in camp “ambiguous”, but am still trying to explore what others think.
@noah.olson, I think you’re drawing an equivalence between “ability to build” and “ready for use” that I don’t agree with, but let’s take it to PM if you want to keep going. We’re quickly gonna hit some technical details that may not be of interest to the rest of the thread.
Anyone else feel free to chime in if desired!
@Nate_Laverdure agree that this is Round Bumpers in a somewhat different form. Not sure what we can do to get people to accept that any rulebook is going to be subject to interpretation.
My goal in creating this post each year is to provide a clearly safe way to meet the code/design availability requirement that, based on my experience, is unlikely to be challenged. It’s not just RIs that might be interpreting this rule – it could easily be a factor in the judged robot awards.
BTW, my comment about linguistics was a reaction to this statement upthread from me:
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.