Hi @mrengineer7777, thanks for opening the thread, have edited the content to our usual description. I'm okay with changing the title. 👍

Topic: Status of release 2.0.8

Topic: Moving master to 3.0.0.
Currently PRs are targeting master, 2.x, or 3.0.0. It's confusing!

Discussion:
A reasonable expectation is that master should always compile and work correctly.
2.x branch has already diverged from master
3.x branch may not compile correctly and still needs a lot of library fixes

Topic: Status of release 3.0.0

Topic: issue labeling and cleanup

Overwhelming number of issues makes it difficult to find actual bugs.
I will suggest new labels and perhaps delete old ones.
Some issues are related to user code implementation and may not be bugs.
Lots of "for reference" issues. These should be added to documentation and closed out.

Topic: PR cleanup

Need help here from Espressif employees! What would it take to implement or close out old PRs?

Topic: Communication

Please talk to us! We have several active developers in this community that know the ESP32 well enough to improve libraries, like me. However we don't necessarily know "why" things were done a certain way, so our PRs may not be acceptable for merging. Need timely feedback on PRs. Help us to help you.

A live comunications channel like Teams or Slack would be amazing. Even email would be acceptable if it doesn't get lost.
Gitter arduino-esp32 channel is used for general user issues.
Gitter esp32-arduino-devs (private) channel can be helpful. Notification of messages is poor and group chat nature means it gets ignored a lot.

Topic: Automatic code formatting

As noted in #7975 , an automatic formatter would save time and make our code more readable.

Topic: Clarify Licensing

As noted in #3121.
Licensing isn't a concern for hobbists.
Is it safe for commercial developers to use code from this repository?
What is the status of adding licensing info to headers?

Topic: CI updates

• CI Testing for External Libraries #8041
• [CI] Added New Board Test #8071

Topic: Breaking Changes
#7942 May break existing projects
#7941 [Merged] Breaks external libraries: ESPASyncWebserver, TASMOTA, etc
#7566 [v2.0.6] PR changed partition structure. Upgrading firmware in field based on v2.0.5 to v2.0.6/7 causes issues due to changed partitions. Workaround: use a custom partition definition.

Topic: Documentation

Been using this framework for a few years now. The technical work by the maintainers and contributors is great. Biggest challenge initially and still now is the overall state of documentation.

A few points and suggestions.

1. Release Notes

A flat chronological list of all PR's included in a release is of little value.

Recommendations:

A. Group and summarize by library, changes in the release. A reference to the PR's pertaining to any given item in the summary could be included.

B. Include as a separate item, a list of all libraries and core changes (i.e. changing all partition files to include the Insights partition???), that have breaking changes. Then in the note for that library state what those breaking changes are. A great template is what is done by the Espressif-IDF team.

2. Official Documentation Pages

It needs to be much much much easier to allow people to contribute. Current method requires that every person who considers contributing to:

• learn the Restructured Text (rst) markup language.
• figure out an environment to create rst documents on your OS (macOS, Linux, Windows) for simple rst previews.
• figure out how to get an environment up and running that replicates the look of the official pages.

All the above are barriers to contributing.

Recommendation:

Publish a "Getting Started" document that points to:

• a simple guide to learning rst
• recommended environments by platform for writing rst documents and previewing as they would be seen when finally published in the repository.

3. API Documentation

As the primary purpose of this repository is to allow Espressif to sell more devices, it must be seen as a priority to provide developers a clear way to use the framework.

Since "Arduino" is in the very name, it is logical that this repository would leverage the official Arduino documentation first. That is, each arduino-esp32 library should operate as its Arduino namesake. This means the API documentation for the arduino-esp32 version library only needs to detail enhancements (and differences necessitated by architectural differences in the SoC used by Arduino and the ESP32 variants) added by the arduino-esp32 library version.

After that, documentation would be added for each esp32-specific library.

Well, in an ideal world that would be the way it works.

Recommendation:

Given the challenge as per item 2. above, and the aversion programmers have to document their work, recommendation is use the @brief method of documenting the API in the header file of each library.

To start, make it a requirement that all PR's starting from date X must add an @brief statement for each function modified by that PR.

We used to say, "If it isn't documented, it doesn't exist." For example, there are a number of PR's that have added good functionality to a library but that addition seldom makes it's way to any document. So, after a period of time, that effort is essentially lost. Putting it into the @brief would at least allow the work to be noted and found in the future. If nothing else, it is a place to park the information until (or if) an section in the official docs pages is created.

While examples are great, they must be supported with good API documentation.

Hi, agenda have been updated in the description.

I just figured out I forgot to share the slides, here we go.
10_Tenth_Community_meeting-Arduino-April_2023.pdf