well, finally I found some time now to post a bit longer answer to Zelgadis’ statements…
As I said, I didn’t want to say anything is wrong in general today.
I am never interested in fingerpointing and understand that all people here are volunteers and are having restrictions in time they might spend.
I do understand the first reason: such a function (to hold back new versions) is needed for preparing for new releases.
Actually I appreciate that we have the chance to do that compared to former times (I think I asked for a function like that myself few years ago…)
On the other hand I just wanted to give you some feedback on how it feels for someone contributing, when a change is not displayed within a short timeframe.
And I wanted to discuss whether or not there is a chance to change something about that.
As for the second reason I would like to call it “Quality Control” (QC)…
QC is definitively a good thing to do, but QC doesn’t come for free, it always binds resources (for reviewing and approving) and it contains a hierarchy thinking (“reviewers know better”),
that has to be handled in a very sensitive way if you have a volunteer situation (I think you know what I mean…).
Additionally, if there are severe time restrictions on the reviewer’s side, then opening a process to less control is a possible option, that gives the reviewer a bit more time while opening the risk of less quality, of course.
As a way in the middle maybe…
we can have clear messages on a timeframe such as “once per week” or “twice per month”.
As soon as there is a fixed date/time for doc changes to be reviewed, discussed and (maybe) approved, then it is much easier to wait for this from a contributor’s point of view.
Hope this helps to understand the reason why I started this topic.
I am open to try out things over time… to find the best way for us all as a team.
BTW: creating forks is, at least in my eyes, the worst thing to do. Instead I would prefer to leave and shut up.