Citation needed.
7 Likes
For better or worse, rules are legislated on the letter of the rule, not the intent. Unfortunately for this specific rule, it doesn’t really have teeth with it’s current wording due to the aforementioned loophole.
3 Likes
Shout-out to @bobbysq for pointing me to this gem (page 4 of the 2019 game manual and R16). More teeth indeed needed to capture intent of this rule (perhaps good feedback for 2021):
1 Like
This, I believe, is the correct answer. No matter what we think the intent of the rule is or is not, as long as you can successfully defend a claim of “available publicly” to any robot inspector, you’ve met the requirement.
The spirit of the rule implies “don’t hoard knowledge, share it with others”. Combined with a culture of gracious professionalism, the end result is that a team will likely share their code in multiple formats, making it not just “available publicly”, but also readily accessible and well-publicized and easy to understand.
It’s hard to nail down what the actual, concrete requirement is. As has been well discussed on CD - the rulebook definition of publicly available does not enforce teams release content in a meaningful way. It gets into the meaning of the word “available” - does available imply some level of usability? If so, what is that level? Is it the same for source code and CAD (probably not)? OR, can we trust GP will prevail and take the I know it when I see it approach, specifically saying everyone gets to be certain in their own opinion and that’s ok since GP guides us toward the same goal?
4 Likes
Most teams don’t think it’s entertaining to have a linguistics debate with a LRI about the meaning of “available publicly” – they want practical advice they can act on.
That’s why my advice on this is crystal clear. If you wish to demonstrate in a conclusive way that you made the code/designs public before kickoff, my suggestion is that you post a link here, include a link on your TBA page, or have a prominent link on your team’s website.
2 Likes
this comment is an editable WIKI now, so please add a row for your team’s public info.
Link to a code release announcement, the code location, and cad location too.
1 Like
There is really no debate to be had and no interpretation to be done. If FIRST wanted teams to announce publication of the design, the rule would have said “… publicly announced and available prior to Kickoff.” If we can’t trust inspectors to “avoid interpreting the text based on assumptions about intent …” then we have a different problem.
2 Likes
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?
1 Like
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.”
11 Likes
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”.
1 Like
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
2 Likes
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.
2 Likes
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.
4 Likes
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?
4 Likes
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.
2 Likes
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 
1 Like
Why are you comparing FRC robot software to an operating system?