Announcing FRC Queue

FIRST General Forum
61

Both valid concerns and ones I shared (as can be seen by my posts earlier on), however as other have pointed out to me, and as I have now experienced first hand, this is not trying to take anything away from any single team, but rather add value (see Marshall’s response to Jon).

If you can’t make use of this app due to poor reception or a lack of access to cellular devices amongst your team, your experience shouldn’t be any different than it normally is. Someone at pit admin can still be announcing the matches as they near, a queuer can still come to your pit and remind you you’re going to be late (if needed), and your team can still follow along with the paper match schedule provided at events.

This app is purely aimed add to the event/queing experience (for both participants and volunteers/event staff), not replace it entirely.

5 Likes
62

I get that, and if I was in the pit with my team (Hasn’t happened since 2011, but whatever) at an event this was offered at, I’d sign myself up in a heartbeat. I’m not saying it shouldn’t be used, but rather that we (as a community) need to be aware that technology solutions like this may not be equitable at an event. In such a case, we need to know that this is recognized, and appropriate training and processes are in place to mitigate it. As a community, it’s worth talking about how that would work, and for those who are enthusiastic about it, even going so far as to drafting ideas for exactly how that work.

For example, going back to @marshall 's thought that this system could allow queuers to “act more effectively for those teams” - how do the queuers identify the teams? What does it mean to “act more effectively”, and how is that different from a queuer coming by your pit every 5 minutes to usher you to the field (something that has been complained about in the past!)?

What are the technology requirements for the volunteers with this system? Are we asking them to run it from their own personal devices, or do we want FIRST to provide devices to help run/manage it? What do we do if there’s a volunteer, like a lead queuer, that is asked to work with this and just throws up their hands and says “I don’t get it, I can’t figure out how to use it”?

I love looking for technology solutions to some of the problems we’ve seen at events, and have even implemented a few locally for inspections (while not being able to go full GMS like I would hope for, but that’s a whole other discussion).

So, in short, it’s not enough to just rave about how great the system is. If we want something like this to be broadly adopted, you need to take a hard look from the other side to say “why would someone involved not be happy with it?” As far as that goes, I think the possible YPP issues greatly outweigh any possible equity issues. The only real way I can see FIRST officially adopting a system like this is if they can ensure no student phone numbers are involved. That would likely mean integration with the FIRST Dashboard, providing a chance from there for mentors to opt-in, as opposed to the more free system that is currently in place.

63

I haven’t used the system and frankly haven’t looked into how it works… but every single team has a driver station laptop at the event. I’d imagine that if notifications can be sent via cell phone, they could also be sent via email (or other computer based notification). This addresses the equity concern and the YPP concern at the expense of the computer based notification having less “reach” than a cell phone notification.

Just a thought.

64

Does the system let queuers know which teams have signed up?

65

In my experience, it is very rare for driver station laptops to be connected to the Internet at competition events, and they are typically not set up with email.

5 Likes
66

yes. It also displays (to registered queuing managers) the last 4 digits of any numbers registered to a team, which can be useful to catch when people enter the wrong information (which happened more than once).

67

Most driver station laptops aren’t connected to the internet for most of the event. I still think the Slack solution is very valid, as is not exposing the full phone numbers to queuers.

It seems there’s some conflation of YPP and PII in this thread. There are certainly situations where protecting personally identifiable informationbecomes a youth protection concern, but one is not inherently the other. The PII concern with FIRST is that HQ will not share contact information they collect. They also require all volunteers in possession of such information to be careful in their handling. However, this does not preclude others from independently sourcing data and using it. Having students sign up for an app that sends them texts when it’s time for the match is no more of a concern than asking students to sign up for something like Slack or Trello or Confluence or Onshape, or any of the hundreds of other apps that teams may use that collect and use contact information or students. I really don’t see how this becomes a YPP concern, and it’s only a PII concern if the information isn’t collected or protected properly.

6 Likes
68

We got to use FRC Queue this weekend at River Rage. It is a great tool in conjunction with the queuing staff and I hope it can be used at more events.

2 Likes
69

I could not get the Slack Integration to load the channel names for our Slack, it’s possible I was doing something wrong. Other than that, the SMS stuff was great.

1 Like
70

Any un-monitored student communication is a YPP concern. As FIRST says in their YPP Program Guide:

Those who seek to abuse or exploit minors may initiate
contact over the Internet by misrepresenting themselves.
In the process they may obtain enough personal
information about a student to enable them to contact
them by phone or in-person and represent themselves as
being in some way related to, or interested in, a student or
their team. It is very important that parents/guardians and
coaches/mentors closely monitor FIRST student online
activities to prevent any inappropriate or unsafe situations

We skirt the edge of this with our use of OnShape (since there is limited chat functionality), but even with that we require students to sign up with their school-based email address, which allows the school to monitor those communications. We don’t use other items like Slack or Trello or Confluence, specifically because those are systems that can allow communication outside of the school-monitored technology solutions. You will never see me text or call a student, because I don’t have their phone numbers. If we’re at an event and I need to get ahold of someone specific, I grab one of our students and get them to reach out for me. That’s all because of the school’s YPP (Yes, in an emergency I do have access to contact info, but I’ve never had to look at it).

I’ve seen enough situations where PII becomes a significant (as-in involving the authorities) YPP concern that I treat all PII as sacrosanct. YPP isn’t about reacting to situations after they’ve happened, it’s about preventing them in from happening in the first place.

1 Like
71

I didn’t try it myself (because I was volunteering), but my team was unable to get the Slack integration to work.

72

I guess I read this differently than you. I don’t interpret a company/business/organization sending automated text messages to students as “unmonitored student communication.” You’re not giving volunteers the freedom to text whatever content they want to students – just to initate an announcement when it’s time to queue. Very different than person ← → person, imo.

3 Likes
73
  1. FRC Queue is not a company/business/organization, as far as I know, it’s a private individual who set up an online service. I really want to stress that I have no reason to suspect anything nefarious here (I really do believe this is exactly what it appears to be), however I don’t know how to interpret this as anything other than an effort to “obtain enough personal information about a student to enable them to contact them by phone” - that’s kind of the point of the service, after all. There’s also, as far as we know, nothing in place to prevent anyone who has access to the backend (like the developer) from directly accessing the phone numbers and doing whatever they like with those numbers. Yes, it’s an automated service… but you’re still giving direct contact information over to someone you don’t know, who most of us have only met online.
  2. No other service we’ve used or considered using asks for student phone numbers. Email addresses, which can and are monitored by the school, yes, but never phone numbers.
    a. If you look through the student registration guide, FIRST doesn’t even ask for contact information for students, only for their parent/guardian. No phone number, no email address.
  3. Any contact information we share with any company/business/organization or individual is designed to be monitored. In the case of OnShape, that means school-based emails, and is ultimately low-risk aside from the possible mentor-student communication that can occur on that platform. In all other cases I can think of, for us it means team-based emails (which are just school-based Google Groups behind the scenes, allowing the school to monitor them and allowing us to ensure at least 2 mentors are included on any communications).
    a. This process has actively allowed us to intercept some very sketchy communications intended for individuals on our team in the past
1 Like
74

I guess this depends where you draw the line. Knowing Evan, he’ll go through whatever hoops he needs to in order to make this as legitimate as it needs to be for events to run. It’s still in beta for offseasons.

It seems to me that your team is probably on the extreme end of this (and that’s totally fine). Most teams I know are using some third party apps where there is certainly contact information being collected.

What about The Blue Alliance? Students who sign up for TBA notifications for their favorite teams are granting TBA information about their email address and Google Profile. Is that a problem? I’d suspect for your team it is, but that hasn’t stopped TBA from being extremely wide spread.

2 Likes
75

There’s a big difference between something unofficial and something that is officially used at events. Yes, this is just in beta, but there have been some big names in the community here stating their intent to push for it to be used officially at events. I only raised these concerns as something that the community might want to look at as people push for it to be used officially. Anyone may say “well, that’s not a concern”… but before you can see FIRST endorse it and allow it at events, they’ll have to make that determination, and I’m not sure they’ll agree with you.

76

If I understood correctly, the whole system is based off a tournament organizer placing a unique QR code into the team envelope. The team envelope can only be collected by a mentor. Therefore it is the mentor’s choice to “expose” 0-5 phone numbers that may be affiliated with their team.

77

This is indeed how it worked at Tidal Tumble this weekend.

78

Not sure I understand the problem with a team simply opting out of it and queueing the old fashioned way.

Another Millennium Prize Problem in the works here, apparently.

9 Likes
79

Anecdata-ly, all of my robotics students at my Title 1 school in the SF Bay Area do have cell phones. They generally do not have their own laptops/PCs.

7 Likes
80

I was a Team Queuer at Beach Blitz this weekend. We used FRC Queuer at the event. The entire development team was volunteering at the event. They provided great support for the tool and were open to feedback from the event.

I’m on board with this tool for events. At Beach Blitz the Lead Queuer made sure everyone queuing had the opportunity to work different positions within the team. I was able to spend significant time with FRC Queuer.

I fully endorse this to event coordinators looking to improve the team and volunteer experience around queuing. It can help keep and event on schedule or ahead of schedule. It reduces cycle times between matches giving an opportunity for teams to get more matches per event, or at least not have matches canceled due to delays in field reset.

We did have to explain the specific terminology used by the tool to team members who have been using a variety of terms for different positions or states of the queue. FRC Queuer uses the following:

  1. Now Queuing
  2. On Deck
  3. On Field

I’ve been Team Queuer for several events during the 2022 Season. The most difficult part of queuing is the filler line with Practice Matches. FRC Queuer made this easy to do. We captured team numbers as we put them in matches. The lineups were immediately available for the scorekeeper. The queue was editable until teams were advanced to On Deck. In all events, the Team Queuers locked teams and positions in at On Deck so the lineup could be passed to the scorekeeper to ensure all matches got presented and logged correctly. FRC Queuer didn’t change Team Queuer responsibilities. It only made it easier to adjust teams as they arrived to queue during Practice matches.

During Qualifications, teams could be checked off as drivers and robots have arrived or only a human representative has arrived. This made it easy to know how many robots needed to be on the field as well as if a robot wasn’t present if the team received credit for the match.

During Playoffs, Team Queuers identified which alliance won the match and FRC Queuer automatically built the lineups for future Playoff Matches. In Best of 3 Playoffs, this would be lineups for Semi-Finals and Finals. Beach Blitz used the Double Elimination Bracket style tournament and FRC Queuer was an ace at working in this mode.

Prior to coming to Beach Blitz, I was talking with a mentor who had been at an event where FRC Queuer was used. That team used the Slack integration so notifications didn’t go from FRC Queuer to individual team members. They went to the team’s Slack channel. The mentor mentioned that is was great for parents who were watching the live stream. They would get the Slack notification and know that was the time to watch the live stream. Then they could do other things when the team wasn’t playing. Helping a remote audience watch their favorite team at an event is a great opportunity. You have to know that team parents are probably not interested in watching eight straight hours of a live stream only o see their team play 8-9 Matches.

FRC Queuer has the ability to include more than one Queuer user at an event. We didn’t use this feature at Beach Blitz. At some venues there are different entry points for Red Alliance and Blue Alliance. It requires two volunteers to check in teams (one at each entrance). FRC Queuer is already designed to work with this situation.

From a volunteer standpoint, I was able to spend more time working with students to make sure they were in the right place and the in-person aspects of the event were working smoothly and less time juggling the Match Schedule or making basic status reports over the radios.

The tool was intuitive to use. It handled all of the unplanned or off-nominal use cases that we had come up. It is clear that the development team has spent lots of time volunteering at events, working with teams, and helping manage and coordinate events. All of this experience has already gone into the tool’s development. Working with the development team, I know the concerns raised here will be taken seriously and addressed in future builds of the software.

7 Likes