Thank you for your question, and sorry for the wait!
We believe there are quite a few different things to gain from actively participating in the Open Alliance.
At Team Rembrandts we mostly value the community interaction and possibility of inspiring other teams with our progress. We have a relatively high amount of resources available to us as a team, so it only feels fair to share our findings with the broader community.
We’re happy to say that throughout the season we are frequently approached by teams who’ve had a positive experience when following (or reading) our Open Alliance build thread. Which gives us only more inspiration and motivation to continue.
We strive to not just tell what we are doing, but actively challenge other people as well, or as our Team Manager Ron put it:
We do realise that value might mean different things to different teams, and some might want something more tangible. Sharing your ideas with the world also means having the ability to get free feedback from everywhere.
And even when feedback might not always be available, explaining every step of your process already helps with being more critical of your own work and prevent tunnel vision.
And finally, if you have a big team, it might be difficult to keep up with everything that happens. We regularly use our build threads as internal reference work.
Since the 2022 season, Team Rembrandts has been putting extra effort into enhancing our media and branding. We believe that a well-managed account reflects professionalism and credibility. Our online activity gives a positive boost to our relationship with partners, friends, family and other teams. Building and maintaining a department like this takes good planning and organization. In this post, we’ll give you a closer look at how our department operates.
Organizing & regulating the department
Our Media & Branding sub-department handles all branding-related activities within the team! This includes creating content for social media and the #TeamREV challenge, designing flyers, posters, business cards, banners, and our team apparel. Team members within our department get hands-on experience with various skills such as concept creation, filming, editing, design, and archiving.
What do we post and why?
When deciding what to post, it’s essential to consider who we’re creating the content for. This is why, before starting any project, we always answer the two questions “Why are we making this?” and “Who are we making this for?”. We use social media to keep friends, family, partners, and other teams updated on our activities, so our content is tailored to this audience. We make sure to write our posts in clear, accessible language for anyone, whether they’re familiar with FIRST or not.
How do we plan these posts?
For our social media we post three times a week, this does differ depending on which part of the season it is. In build season we post more than in off-season. To stay efficient with frequent posting, we make use a content calendar. A different calendar is made for every off-season, pre-season and build season. With this calendar we can keep a clear overview of posts, who is responsible and the status.
Our content calendar is planned out before the start of each season. Right now, we’re working with our pre-season calendar created during the off-season. We begin by scheduling essential posts, such as partner highlights or event recaps—these account for about one-third of our weekly content. For additional posts, we often draw inspiration from other teams or revisit ideas from past years.
Over the past two years, we featured our “Team Member” posts, but this year we wanted to try something new. So, we introduced “Team Memory” posts, a twist on the original idea. These posts make up two-thirds of our content calendar. Last year, we launched our “TR-X” video series. Building on that, we created the “Bring in the Dutch” shorts for this year, adding another engaging series to our lineup: The Fire & Mango X Media & Branding collaboration. With this, our content calendar for pre-season was complete!
Our content calendar includes much more than our social media posts; it’s also a planning tool for our larger projects. At the start of each different part of a season, we create a list of upcoming, already-known projects for the year. These might include REV review videos, our annual reveal video, weekly build season recaps, and our TR notebook, among others. Having these projects laid out in the calendar helps us keep track of deadlines, which are essential for staying on top of our media and branding goals!
Future Steps
We will keep our Media & Branding department running smoothly as it is now, trying to produce the best content we can! Within the upcoming time, more posts about video production, designing and how to start up your brand will come online!
And know, if you have any questions, don’t hesitate to ask them!
This post will provide you with tips and tricks we use to fully utilize all formatting capabilities of Chief Delphi to make the posts enjoyable to read.
Markdown Syntax
Chief Delphi is a Discourse application that allows users to write their posts using Markdown syntax. This formatting code is pretty easy to use, but it needs some practice to get the hang of it.
Here is a quick list of Markdown codes we use for our posts:
Headers
Main post title
For the main title of the post, we use an H1 header:
# Main post title
Sub Section Title
Subheaders (H2) are styled in orange for consistency with our team branding:
We upload images using the upload image button in the editor or by copy/pasting the image in the editor. We also add some extra code to align the image to the center of the page.
We upload our videos via YouTube. To display them properly, we put the youtube.com link in the editor and give it some free space above and below. Chief Delphi will automatically embed the video if you do so.
https://www.youtube.com/watch?v=8aKmVmH01bA
Links (with color)
Coloring links is a great way to make them stand out and match your team’s style. Here’s how we do it:
For displaying code, use triple backticks for a clean block format:
"Written by" Section
Written by: @YourName - [Your Function] @Bjorn - Chief Editor & Lead 3DM
The “Written by” section adds a personal touch to each post. We use this format:
<hr>
<div align="center">
Written by:
@YourName - [Your Function]
@Bjorn - Chief Editor & Lead 3DM
</div>
Post Structure
For our official OA posts, we use a standard format to give the writer an initial template to start from. The structure looks as follows:
Main post title
Short introduction of post content
Subsections where content is shown
The last subsection concludes the post and highlights future steps
If possible, ending with a fun meme or cool video to keep the readers entertained
Ending the post with a “Written by” section
We also use some guidelines like not making posts too long and using a lot of images/videos to make posts more enjoyable to read.
TR Build Thread Buddy
Of course, we are also making good use of AI. Some of our team members are struggling with writing and prefer to use ChatGPT. Normally, it can help them, but ChatGPT will probably not have enough context to make good quality posts. Therefore, I build us our own GPT called “TR Build Thread Buddy” which has context on our team and how we format our OA posts. If you want to try this out, go ahead and click here.
We’ve made a lot of progress since last season on formatting our posts, and we are pretty happy with it. I would like to make a better guide for our team members to format posts themselves (although I now realize that I should probably refer them to this post ). The GPT could also be trained more to better fit our team’s narrative and formatting style.
I hope that this formatting guide did a good job in explaining how we format our OA posts, and if you have any questions, don’t mind sending them here!
This is an impressive level of work by the team. I’m curious if many of the students had much work with HTML/CSS prior to or after working on Open Alliance posts?
Thank you!
I don’t think that our students have that much HTML/CSS experience (yet).
Most of the formatting was either done by me or by our GPT.
The reason for this is that we wanted to divide the OA workload over the team while still having individual responsibilities. This process of posting works as follows:
First, students and mentors will come up with OA post ideas and sent them in our Slack channel. Together we then brainstorm to define what the content of the post should be.
After that, I’ll ask if the person with the idea also wants to write about it and if not, I’ll ask a representative from the relevant department to find someone that is able to write the post.
We create the to-do card in Slack and assign a deadline for when the post should go online.
When the person is done writing, they’ll change the status of the post to “review” on the planning board, and our Slack Workflow will send out a message asking others to review the post.
After reviewing, I make sure that the post is in the right format and will ask the writer if they want to post it on CD or if they prefer to let me post it.
When the post is online and people start replying to our content, we use a Python script (see image below) to automatically send a notification in our Slack channel so we can discuss who is able to answer the question and sent out an response as soon as possible.
In this way we can ensure that the posts have the right quality/format and are put online in-time, while also trying to respond as quick as possible to any replies (which we really like to see of course ).
Might have gone a bit off-topic here, but I think it’s nice to show our way of working as an OA team.
If only we knew!!! Aside from all of our hard work on the robot, media & branding, and outreach, we’ve been putting significant effort into improving our awards submissions. Of course, we don’t have the exact formula for the best way or process to create award-winning submissions, but what we can do is share the insights we’ve gathered from other teams, their methodologies, and our own practices.
This (off-)season, we took important steps to understand what differentiates a Hall of Fame team from others, so we could apply these insights to our own writing process and approach to creating submissions. First, we studied how teams develop their profiles and communicate their information to the judges.
Our quest began at last season’s World Championships, where we attended the “How to Impact” convention hosted by Hall of Fame team and now also 2024 World Champion team 321 Robolancers. At this convention, we gained many clear insights and answers to our questions. For those interested in the full conference and the many resources Robolancers offer, you can visit: Robolancers: “How to Impact”
We also discussed our awards strategy with some very experienced members of the FIRST community, such as Amanda and RBB. By combining our own knowledge with their structured approach, we developed a new way of working that aligns with key takeaways from their perspectives on awards. This new approach is now helping us refine our process for creating submissions.
Key Insights from the Journey
Define Your Community:
Clearly defining your community ensures your impact is measured accurately. For us, being situated about 8100 kilometers (or 5000 miles) away from Houston, this means describing our Dutch culture, school system, and community in a way that (American) judges can understand. It’s not just about translating kilometers to miles; it’s about translating who we are.
The Golden Circle:
A concept we’ll dive into later (spoiler alert: it’s not just a fancy term for a really shiny hula hoop).
Differentiate Yourself:
321 taught us about the importance of differentiating your initiatives through active engagement in awards scouting. Think of it like a talent show: where everyone’s juggling similar balls, but how do you make your act stand out?
This approach helps highlight what makes your team unique when speaking to judges in the pit and during presentations. Additionally, emphasize the differences in your impact—even if your numbers are lower—by framing them in a way that highlights their relative significance and value.
Starting from the Ground Up
This off-season, we began by asking:
What does each submission ask from us?
What information should be included or avoided?
What kind of data is relevant?
What’s the overall goal of the submission?
And most importantly: What role does this play in telling our story?
(Okay, maybe not that last one, but we did consider if these submissions would one day help us win an Oscar!)
Takeaways So Far
We’re still figuring things out and will continue to do so throughout this season. But hey, we’re off to a great start with our submissions. And if there’s one thing you can learn from us awards-wise, it’s this: Make contact, ask questions, seek help from the hugely experienced members in our community, and above all, keep learning.
After all, the road to the Hall of Fame isn’t paved with perfection—it’s paved with persistence, a bit of trial and error, and maybe a few late-night snacks.
While our team really enjoys writing Open Alliance content, having more reader engagement on our OA Build Thread motivates us a lot. We therefore have been thinking about how we can make posts enjoyable to read and how we can reach as many people as possible. This post recaps our findings.
Tips & Tricks: Writing Content
Know Your Audience
Chief Delphi readers are primarily FRC students, mentors, and alumni who already have a good understanding of FRC. Keep this in mind when writing your posts—there’s no need to over-explain the basics. Instead, focus on sharing insights, lessons learned, and details that add value for an FRC-savvy audience.
Be Consistent with Formatting
A clean, consistent structure helps readers digest information. Use headers, bullet points, and bold text to highlight key points.
Tell a Story
Narrative-style posts resonate more with readers. Explain the “why” behind your technical choices or strategies, not just the “how.”
Focus on Visuals
Posts with images, videos, and GIFs are much more engaging. Always add captions to clarify or provide context.
Engage with Your Readers
Encourage questions and discussions in the comments. Building a connection increases post visibility and engagement.
Proofread and Polish
Before hitting “post,” double-check for typos and ensure your tone matches your team’s voice.
Incorporate Humor
Adding a bit of lightheartedness makes posts fun to read. GIFs, memes, or clever phrasing can go a long way.
Experiment with Post Length
Not every post needs to be a deep dive. Alternate between shorter updates and detailed technical breakdowns to cater to different audiences.
Collaborate with Team Members
Involve your team in crafting content. Multiple perspectives make for richer posts and reduce the workload.
Just do it!
There are a lot of things to keep in mind when posting on your OA build thread. However, teams are often overwhelmed during build season and forget to share their progress. The most important tip? Just post something!
Even a quick update with a photo or short description can keep your thread alive and engaging. Perfection isn’t the goal; consistency is. By sharing regularly, you’ll create a habit of documenting your team’s journey, which not only helps the community but also serves as a fantastic archive for your own team.
Chief Delphi Traffic Analysis
We were curious to find out when most CD users are active on the platform, so that we can put our posts online at that time. Here’s what we found:
We wrote a Python script that collects the amount of views and new posts on the homepage every quarter. The data shows that while the morning and evening hours see high activity, the best time to post is between 3:00 PM and 4:00 PM (GMT) . Why? During this time, viewer traffic remains high, while the number of new posts is moderate. This means our content is more likely to get noticed without being drowned out by too many other new posts.
It was very cool to see this pattern and it resulted in a new posting strategy for us. In conclusion: yes posting time matters, however if your team wants to grow your OA audience, I would highly suggest to focus on the consistency of posting and make sure to use a lot of visuals like images/videos/GIFs.
POV: Trying to use 3DM skills on getting more views on CD
Note, you can also use a list of different languages (python, cpp, etc) after the first backtick set to color and format the code specifically to the syntax of that language.
I first found out through the discord markdown guide, then realized it works for CD too! definitely good to clear up any confusion about languages when talking about code here.
A couple of weeks ago, we talked about our new approach to working with a large software team. While that post highlighted the changes to our architecture in order to do more concurrent development, we never described a process to effectively merge the changes made by different people.
As you can image, merging code written by 10+ different people gives way more operational overhead than having just a couple people in a Live Share. In such a big group “protecting” ourselves from eachother becomes much more of a priority. This means having stricter requirements for merging back into the main branch.
CI Pipeline 🔄
While the final code review will still have to be done manually, automatically checking a few things beforehand can save a ton of time. Everytime someone creates a merge request to the main branch in our GitHub repository, our Continuous Integration pipeline will be executed. This pipeline consists of several steps:
Build & Test
The first step is the most crucial. This step checks if the code can build without issues. The latest commit on the main branch should always be able to be deployed on a robot. If your code does not build, it cannot be deployed.
This is also where we could possibly run unit tests in the future, although as of yet, we have not found anything worth writing test cases for. If your team uses unit tests, or you think something is definitely worth testing, we’d love to know!
Note: if you would like to implement such a pipeline as well, it is important to realise that
p \implies q \not\equiv q \implies p
in other words, failing a step in this process means that your code is not correct, but passing everything only guarantees the absence of compilation errors.
Format
The next step is checking whether the code is correctly formatted. There are many different ways to format code, and people have lots of opinions about it. But the most important thing is that no matter which style you choose, consistency throughout the entire codebase is key.
To check the formatting, we make use of the popular gradle plugin Spotless. The CI pipeline only checks if the formatting has been applied correctly. The formatting itself can be done through gradle actions inside of the IDE.
Deploy
Contrary to the previous steps, this workflow is only applied when a branch is merged succesfully. In the case of the library, we generate and deploy javadoc to Github Pages to further improve usability.
Splitting the Project 🪓
As mentioned before, our codebase is split up into two different parts: robot and library.
Quick recap of the differences:
In our original setup, both lib and robot were packages inside the same Gradle project, with lib being a git submodule. This works, but it did not allow us to develop the library outside the context of a robot project. This also meant that we could not set up a CI pipeline for the library.
Sub-projects
Because the CI pipeline is arguably more important for the library than the robot code, it became necessary for the library to become it’s own Gradle project. Fortunately, Gradle supports sub-projects. This means that we can have a project that includes two other projects.
Below you can see a schematic overview of the changes:
Changing to a new, non-supported system might seem a bit paradoxical, considering standardization was one of the biggest hurdles with our old system. However, that standardization was mostly about the code itself, which hasn’t changed. Even the package names are still the same. So the only noticable change for newer students is having their code in a slightly different root folder.
Lack of Support
The only real downside is a possible lack of support when dealing with build files. But this should only be a problem when making big changes. In the past years, we only ever touched our build files when updating WPILib versions, or when installing AdvantageKit.
Having some expertise in build files and DevOps creates the possibility for new roles in the future, but that will be a problem for next offseason.
Code Release Update 💻⬆️
To reflect the changes we made to our codebase compared to the previous post, we have updated the example project that we shared last time:
For compatibility sake, we’ve combined both repositories in a single public repo, but this has not made a change to the functionality discussed in this post.
Future Steps 🚀
While our current implementation works, we are quite certain that this is not the most optimal way to do things. Working with Gradle build scripts is new for us, so if you spot any errors or weird things, we’d love to hear about it!
). The GPT could also be trained more to better fit our team’s narrative and formatting style.
).
