Developer meeting (22 June 2022)

[knmcguire]

Based on this poll we will have our developer meeting at 13:00 CEST (Sweden time) on Wednesday 22th of June 2022. We will aim for an hour but depended on the discussions we can last an other hour longer 🙂

As this is our first developer/townhall meeting, the topic istabout how to handle support and how the new Github discussions are treating you and us. Ofcourse let us know here if you would like us to discuss anything else, if we have some more time.

On the day of the dev meeting itself, I will share the google link in this discussion thread. Don't forget to give a 👍 as confirmation that you still want to join.

=================

MEETING LINK: No longer available.

=================

Notes of the meeting can be found below in the comments!

[Bikerholic]

How can we join in this meeting if through google meet how can we get the link

[knmcguire]

Ah sorry if it was unclear! I will share the link in this exact discussion thread on the day of the dev meeting itself. So just keep an eye on it 😄

[knmcguire]

The developer meeting is tomorrow already! I see already 7 thumbs up so that is a good start!

Just a reminder that a developer meeting is not for face-to-face support handling, but an indepth discussion about how we handle support (feedback on the new support platform, how to suggest answers, when is something an issue or a question etc).

I'll share the google meet link tomorrow.

[knmcguire]

The meeting link will be at --. Don't forget to mention topics you want to talk about in the sense of support handling or organizing developer meetings in general.

[whoenig]

Topic idea: How to find anything (now we have old wiki, old forum, new discussions, and various webpages). Might be nice to have a feature on the webpage that meta-searches across these sources?

[knmcguire]

It will start in 15 minutes approximately! I'll probably be a few minutes early to let people in the google meet.

looking forward to it!

[knmcguire]

Bitcraze Developer meeting Notes 22 06 22

This was the first developer meeting that bitcraze developed ever! So this time we wanted to talk more about support handling, and developer meetings in general, and some other topics that came up after these discussions. There were about 8 -10 people who joined, so thanks to all the participants (I'm leaving out names for privacy reasons) We already had some good insights from some of your feedback!

Why developer meetings?

• We organize the online BAM days and miniBAMs, and there it is usually about showcasing the Crazyflie, which is great to see as well. However these events do not give a lot of room for discussions in general.
• During conferences we usually like to talk to our users and get feedback on our work, or ask what they think about our prototypes. We want to have this moment multiple times in the year and not only during conferences, to be able to talk to our fellow crazyflie developers and users.

Support handling

• Github Discussions vs our old Forum: In general the new discussions seemed to be well received by the users. The old forum has a lot of information on there, that we unfortunately can not transfer all to github discussions, so it will stay in read-only for a while. It is a nice feature to see the questions with the selected answer in the Q&A, as that is what we tried to solve with adding [SOLVED] in the old forum (but that was difficult to maintain)
• Handling each discussion topic: We handle support now in the Q&A, and usually we have to ask for more information as the support question itself doesn’t contain environment information etc. We talked about if it might be useful to add templates to discussions, therefore ‘forcing’ users to provide more information. But it might be better to save that for issues instead to keep the ‘low bar’ of people posting a question.
• Issues vs discussions: If a bug is very clear to be originated in a repository, it is probably better to create an issue instead of a global bitcraze discussion. However, sometimes it is more vague than that, and how about wanted enhancements? In general, pieces of work should be issues according to github, but if there is anything vague about a question or bug, https://discussions.github.io// should be the default. We could turn a discussion into an issue if necessary but that is more difficult than the other way around, so perhaps it is better to start a separate issue and link it in the discussion).
• Community participation: On the old forum, users would show more of their work in the forum itself, but we haven’t had that in the last years as much. In case of the discussions it might be just too new for some. It can also be due to the change of demographics of our users: before it used to be more maker types that communicated on these forums, now there are a lot more academics that rather want to publish and communicate afterwards. We did notice that there was more reaction to publications notices that we would release and guest blogposts, where the communication would start with us first. One mentioned that perhaps our publication search on our website should be improved, as that is the way that researchers communicate their work, and others would like to read those. It is already of very good value that we keep up this list of crazyflie publications.
• Extra question: How to deal with searchability of old sources? Our wiki and forum are still searchable, but only from google. As these are archived technically, it was suggested to make it easier for users to search trough this old sources. Perhaps we should implement a search engine based on google on our website were people can still find information on these.
• Extra question: How categories now work in github discussions? Before in the old forum, categories were very strict and separate from our ecosystem (positioning systems, crazyflie, crazyradio). Now we only have the github discussion standard categories (announcements, general, Q&A, etc). The ecosystem based topics are now handled by labels of each discussion, which can be filtered out with ‘label’
• Extra question Tthe usage of the GitHub Action script in the cf-firmware repo: It is very handy to use this action scripts for testing of the firmware but one said that they rather would like to have actions for more individual component. That is a good idea but we think that the toolbelt is a better solution for this for testing out parts of the code: https://www.bitcraze.io/2022/02/the-toolbelt-making-development-easier/

Developer meetings:

• How often should we have this? Some projects have it every week, but that is too much in our book. Perhaps every month or every quarter is better? Here it was argued that perhaps it is better to make it dependable on which topic we would like to talk about at that moment, based on our planning or the community interest.
• About what kind of topics? We could start a discussions list or poll to gauge what the community wants to hear and talk about, and if we have a handful of these topics , just to organize one ad-hoc.
• The announcements: We tried out github discussion announcements for this, but apparently this is not visible for many. The notifications on github itself disappear in the many comments, so it need to be seen by people by chance. Next time we should announce it on the (latest) blogpost and on some social media channels more clearly.
• Extra question: It was commented that it would be nice to share more about our planning within Bitcraze, in terms of what we want to work on. It is sometimes tough for us to share our planning as we working with special lean development that is unique, which actually enables us to work without deadlines (at least internally) but keeps us flexible. This means also that our planning or roadmap has to be taken with a grain of salt, as it is not fixed in stone and can change. However, we do agree that we could look at ways to increase our transparency, and perhaps share on github discussions what we are currently working on that we rather don’t want to share as a blog for now. An suggestion was given to use a public online Kanban document is a good way to show it, there are many tools that could be used, such as the "Project" Page of a github repo, or Notion. We will discuss at Bitcraze internally what would fit the best with our current way of work.
• Community feedback: It’s hard to give support on specific issues, but there was a desire to have more generic discussions on support/issues with products. We’re also interested in getting feedback on issues the community might be having.

Extra topics:

There were some questions about the AIdeck which are too detailed to mention here. Also Skybrush was mentioned, but we can’t help with that yet as we haven’t used it often yet (but we want to soon!)

Conclusion:

• The Github discussions are received well, especially the selecting answer function. If any bug is vague where the origin is, the standard is to start a GH discussion,not an issue. Community participation we should try to encourage more by sharing publication better
• We should have discussion meetings not with regular intervals whenever we have something to talk about, so we will start a thread and see what people are interested in. Announcements should be shared on social media and blogs for more visibility and we will try to find a way to improve transparency on our road map or at least share what we are working on this new communication platform.

[knmcguire]

Let me know if I forgot anything!

[RavenLite]

Let me know if I forgot anything!

Look great!

• Maybe you forget our discussion about the usage of the GitHub Action script in the cf-firmware repo. It's really a useful tool for us to use it test our forking repo, but maybe we only need some particular steps.

• What's more, I have a suggestion about the transparency on your road map. A public online Kanban document is a good way to show it, there are many tools that could be used, such as the "Project" Page of a github repo, or Notion.

[knmcguire]

Thanks @RavenLite! I've updated the document