Thanks for your reply, Scott.
My observation is that the project team periodically creates a branch in the repository, populates that branch with five commits that based on the commit message contain "code", "tests", "documentation", "configuration", and "license" updates, merges that branch, and then deletes it. Based on this, I assume that they're doing their actual development elsewhere, most likely in a server that sits inside the corporate environment.
If this assumption is incorrect, or if I am missing something important, please advise.
The fundamental problem with the approach that I've observed is that it makes the project completely impenetrable to anybody who does not have access to the repository where the day-to-day work is actually happening. Making changes and contributing them back to the project is extremely difficult when the day-to-day evolution of the code is not accessible. That is, the project is cutting off most of their potential for contributions from outside of the core team themselves.
The
open source rules of engagement in the Eclipse Foundation Development Process define three fundamental principles of open source development: openness, transparency, and meritocracy.
While this teams mode of operating is at least nominally transparent, it is not particularly open to participation by others, and without being open to participation by others it is impossible to develop any merit to earn privileges with the project. Note that I describe the team's practice as nominally transparent because the commit record doesn't actually tell a story about the evolution of the content, it just records that changes happened.
I am happy to discuss this further. It's important to me that committers and project leads understand why we have the rules that we have.
I've written some blog posts on this topic:
Wayne