This is going to be a long post, because Victor has made a number of points that I want to address in turn for the benefit of the whole community.
On the feedback from the TSC
TSC members who felt that their feedback was relevant to improving the proposed REP document itself provided commentary on the PR. Other TSC members may have felt that their informed opinions were less useful as feedback and more useful for allowing all TSC members to make a fully-informed vote. These opinions don’t necessarily need to be conveyed to the authors of a proposed REP nor made public. TSC members are not required to comment on or contribute to a proposed REP in order to take part in the review process.
Furthermore, the feedback given by the TSC as part of the voting process is an ad-hoc process change made by @Katherine_Scott, the TSC chair. This change was made because it is important to have more transparency on why TSC members voted the way they did, allowing REP authors to potentially address those concerns and resubmit the proposed REP.
The feedback provided after the vote by the TSC is in agreement that the TSC would prefer the content you are proposing to be in the documentation rather than as a REP. This is probably in part based on the claim in your proposed REP that, although you state that the proposed REP is informational, the “guidelines in here are intended to be a living document that can be updated as new information becomes available.” REPs are explicitly not meant to be living documents. They are set in stone once they are accepted and published, and changing a REP means making a new REP and deprecating the old one. This is necessarily a long process. On the other hand, updating a documentation page is an easy and common process involving a simple PR.
On informational REPs
Although the original REP describing the processes around the REP (written in 2010, since when a considerable amount has changed in our community) does include the informational REP concept, this is not a requirement for proposed informational REPs to be accepted, particularly if there may be a better way to present the information.
Moreover, informational REPs are still meant to contain information that is broadly agreed upon. Reading over the PR discussion and relevant threads on Discourse does not convince me that there is a broad agreement, let alone a consensus. Perhaps the TSC members felt the same.
I also note that you have mixed up “informative” and “standardised” in multiple places in your posts. You state that the REP is intended to be informative, then make statements such as “TSC voted 3/12 against standardizing a benchmarking approach in ROS 2.” The REP cannot be both informative and set a standard at the same time. If your goal is truly to get the information out there so as to inform users of ROS one way to do benchmarking in order to encourage more of it to be performed, then a page in the documentation would be sufficient. An informative REP shouldn’t hold significantly more value for you, especially given its lower visibility.
On the REP process
I agree that the REP process needs an overhaul. Fortunately the OSRF is working on a new REP process as part of its year-or-more-long transition away from the old BDFL project governance model that the OSRC represented. We will call for community input into this at the appropriate time.
However, we can’t revise the process and apply it retroactively.
The current process, however ad-hoc, is the process we have at this time and we must follow it until a better process is put in place. Part of this process is a review by the TSC of any proposed REPs; this review does not require that any TSC members be involved in drafting or commenting on the REP itself, and not doing so does not mean that the TSC has not been a part of the process. Neither do TSC members need to be “technically qualified on the topic” or experts. Being able to explain a REP to non-experts is part of the point of the review.
And finally, no one is required to make “active contributions” to a proposed REP to have their comments heard or acted on by the authors. If a proposed REP does not incorporate all requests simply due to available time, then that proposed REP should not yet be accepted.
On TSC membership and its expertise
You seem very unhappy with the way that new members join the TSC. The requirements for a new member joining are open and published in the TSC Charter and in the Project Governance section of the documentation. There are no TSC members who “enter[ed] by the back-door” because there is no “back-door”. The only members who did not go through the current entry process are those founding members who were part of the initial batch of membership or joined shortly thereafter, before a more formal process for joining involving REP 2005 and an incubation period was put in place.
I’m not aware of “10+ startups” who have applied and been rejected stealthily. All membership applications that I have seen come to the TSC membership have involved a prepared document from the applicant, discussion by the TSC (confidential, so opinions may be honestly expressed), and an anonymous vote. The applications are documented in the public minutes. In the past couple of years I can think of one company that was rejected for not meeting the requirements, and one company that went through the same process and was accepted. I do know that one company has been removed recently by a decision of the TSC for lack of attendance, and one other company was at risk of being removed until they clarified their standing.
I also want to make it clear that TSC membership is conferred on organisations, who assign someone from their organisation to represent them on the TSC. Organisations may change their representatives at any time. This happens for a variety of reasons, including internal promotions, leaves of absence, change in role or responsibilities, and resignation.
I wish to also ask you to scale back the ad hominem attacks you are making on the TSC members. Using descriptive phrases like “the corporates” and “backed by X company”, and stating that most of the members of the TSC have “never contributed to a REP, or ROS with relevance” are not helpful, not correct, and are divisive.
Running down the list of the TSC representatives who attended the June TSC meeting (I selected June because July and August meetings typically have lower attendance due to summer vacations):
- Ralph Lange and Christian Henkel have been involved in ROS activities for years, and lead the groups in Bosch that do make heavy contributions.
- Jaime Martin Losa’s company produces the FastDDS package on which much of ROS relies.
- Angelo Corsaro’s company produces the Cyclone DDS package on which much of ROS relies.
- Chris Lalancette from Intrinsic is the project leader for ROS.
- Lou Amadio from Microsoft is an engineering leader who has shepherded many important contributions to ROS from his company.
- Tomoya Fujita from Sony has contributed more to the core of ROS than most of us, and other engineers from his company are likewise significant contributors.
- Ian McMahon from TRI is a very long-term contributor and represents a heavy user of and contributor to ROS.
- Henning Kayser and PickNik have been involved in ROS for many, many years and made huge contributions.
- Jeremie Deray and other engineers from Canonical have contributed a significant portion of the security capabilities of ROS. (The Canonical representative has changed to Mirko Ferrati since the June meeting was held.)
- Michael Orlov from Apex.AI leads the development of ROSBag2 and other engineers from Apex.AI have been heavy contributors for a number of years.
- Alberto Soragna and other engineers at iRobot are heavy contributors and have provided much of the current knowledge on executors.
- Adrian Macnell from Foxglove (a startup) and his engineers (although he’s one, too, but now he has to run a company) provide arguably the best visualisation solution for ROS, contributed the MCAP format and its myriad of client libraries, and have made heavy contributions to ROS.
- Jerry Towler from DEVCOM is a long-term contributor to ROS.
- Aaron Blasdel from Amazon has a long history of contributing himself, as do many other engineers from Amazon.
- Matt Robinson is the current lead of ROS-Industrial.
- Andrei Kholodnyi and Wind River are some of our leading expert contributors on real time execution.
Although some of the people on that list are now in management positions, I’m not aware of any who are not engineers. I certainly wouldn’t describe any of them as “corporates”.
I think it is also worth explicitly noting that while the majority of the TSC members are “from industry”, that does not make them a separate group from “the community”. The ROS community is made up of a diverse mix of hobbyists, students, and professionals. Giving “the community” an “equal say” to “industry” implies that those members who use ROS for work are somehow separate from the rest of the ROS users. Although TSC members who represent a company are in part representing their company’s point of view, they all do it in a way that is balanced with their views as part of the community and what is best for ROS as a whole.
For a purely non-industry point of view we have the three community representatives. I have seen complaints that some of the community representatives are not active. If you do not agree with the activities of a community representative, the correct course of action is to not vote for them the next time they stand for election. This is one reason why I encourage everyone to think seriously about who should be their community representatives and vote accordingly. The next community representatives election will be starting in September.
Politics and “anonymous lobbying” in the TSC
I’m not aware of any politics or “anonymous lobbying” in the TSC. If you are, I encourage you to provide specific examples so myself and Kat can correct that behaviour.
I also encourage you to clarify your statement that working with the TSC is “complicated”. Broad, generic statements like that do not help us improve processes. Specific problems and examples of them do.
On the ability to contribute to ROS
Can you please be more specific about what policies the TSC is setting that have “changed rapidly in recent years”? I’m not aware of a rapid change in how ROS is run as a project other than the instantiation of the TSC itself.
I’d also like to hear specific examples of it being difficult to contribute to ROS, so we can understand why someone found it difficult to contribute, and try to improve that experience. However I note that the TSC does not gate-keep contributions to ROS other than the REP process, so there shouldn’t be any involvement by the TSC in making new feature or bug-fix contributions to the source code.
On confidentiality and transparency in TSC discussions
The TSC has rules about confidentiality for good reasons. Members must feel free to give their opinions honestly and openly without fear of reprisal in any way in order to encourage free discussion. Confidentiality is rare in the TSC, and typically relates to things such as forthcoming product launches, interpersonal discussions, and potentially contentious votes.
Confidentiality may seem to contradict the desire for transparency, but the TSC has so far been able to balance both. We think the trade-off of allowing confidential discussion to occur when necessary is worth it.
The TSC charter, which you linked to, is clear that any information not given in the public minutes should be considered confidential by all TSC members. It also specifically states:
- 1 - Statements made by individuals in discussions surrounding a vote or topic of contention which are not reflected in the publicly posted minutes should be considered confidential.
- 2 - Statements made by individuals regarding companies, research groups, individuals, or other entities for which they are not also members should be considered confidential.
[…]- 5 - Affiliates of TSC member organizations or guests of TSC events privy to confidential information will be held to the same standards set out in this section.
If a member of the TSC has been passing on to you confidential discussions and comments from other TSC members, then that TSC member is violating the TSC charter. If the member does not agree with the rules of the TSC, then they should either raise this during a TSC meeting (and comply with the charter until it is changed) or voluntarily leave the TSC. Breaking the rules just because they do not agree with them is not acceptable or professional conduct.
On the “slowdown” in Discourse engagement/involvement
We’re not seeing a slowdown in Discourse engagement and involvement. At worst, it’s stable. On some statistics, it’s growing. This can be seen in the Annual ROS Metrics Report that @Katherine_Scott spends a great deal of time and effort putting together for the community. It is also visible in the inbuilt Discourse statistics, shown below. The following data is monthly; it is not cumulative.
