Community Attendance in API Reviews

[robloo]

This is a request for API reviews to be opened up to community attendance. Everything is now discussed behind closed doors. When last this was requested it was stated there are no plans for community members to join. However, comments in GitHub issues may not be fully understood or presented in these reviews. I don't think that's ideal for an open source project.

Open source excels by collecting ALL feedback and viewpoints and condensing it into something better than would otherwise be possible. While groups are not great at actually doing the core work, they are great at finding bugs, inconsistencies and better ideas. This is ideal for design reviews.

I expect there is concern have community involvement would slow down the meetings and derail the discussions. However, most won't have the time to join. Of course and there could also be some criteria set -- such as must be a contributor and following the project for a bit of time.

There is a wealth of experience in the users of Avalonia and we also have some control library authors and such that I'm sure would have invaluable feedback.

[MikeCodesDotNET]

At this time, we have no plans to open up our internal API review process to the community.

We have also debated releasing recordings of the meetings, but decided against it. The benefit of these discussions being private is that the team can be candid.

Publicising these sessions inevitably changes the dynamic from a working session to a presentation. We need a space where the core team can debate rough ideas and iterate quickly without the pressure of an audience.

[robloo]

The benefit of these discussions being private is that the team can be candid.

I think everyone benefits from candid discussions. However, yes, it would force ideas to solidify faster and be more professionally discussed. That's not necessarily a bad thing though. Most significant contributors are used to professional environments with strong/constructive feedback as well.

We need a space where the core team can debate rough ideas and iterate quickly without the pressure of an audience.

Well, it would be volunteer contributors that can help and benefit the discussion. Engaging the community this way would solicit more involvement in prototyping and solidifying ideas faster. Additionally, in a more structured scenario, it would actually be the core team that is the audience.

There are a number of ways a compromise could be reached:

• As mentioned, require community attendees be prior contributors and have been following the project for some time
• Community attends for only publicly known features
• Community members attend by invite-only and only for features where there is an interest or point of input
• A big one would be to require the community members to present their ideas / feedback in a structured way (slides, etc.). The core team wouldn't be presenting -- they would be the audience. You would be hearing ideas in a structured way to do with as you please.

Even if the community doesn't attend these meetings we also have little idea when certain features are being discussed in API reviews and finalized. This means adding comments to GitHub isn't always possible or done in time for consideration.

The hesitation to leverage the community in this way is disappointing. Historically, it wasn't an issue when the project was primarily GitHub driven. Nevertheless, I will respect the decision but ask that it be re-evaluated from time-to-time.

[thevortexcloud]

Perhaps as a compromise a summary of the minutes can be released instead? It will stop specifics from being released but still allow people to get a sense of direction.

[robloo]

Well, a summary of minutes is a different ask. I was primarily looking for a way for the community to directly contribute with API design reviews and core control development. I do think there is a lot of experience in the community that is being left out.

I would classify minutes as part of understanding the roadmap -- which is definitely useful. This would help the community know what is being looked at so GitHub issues can be focused on.