I'm a passionate developer who sought to invest in open source contribution. So, I've learned how to contribute through posting questions/answers on GitHub, issues and pull requests, reporting bugs ... For now, I would be glad if someone could teach me how, when and where the responsible committee (or whatever, and who these persons are ???) do manage versioning . I.e what features will following minor/major version consists of, what pull request/issue fixing/bug fix/patch or whatever should be validated or not, ... I've looked for these topics on various open source projects documentations but to no avail. My question pertain to open source projects in general. Thank you very much all. Have a nice day.
Your question is unanswerable, because there is no answer that applies to a large portion of the open source projects.
Each and every project decides for itself who gets to determine when to make a release, what to put into that release, what amount of verification & validation is needed, what version identifier to assign to the release and if and how to document all of this.
Open source projects range from the very small one-person projects that only get used by the developer him/herself, to fairly big organizations that have a reputation to uphold (like Debian or the linux kernel) and there are no guidelines that could possibly apply to all of them.
There is not one answer which can say "this is how people do it" - as every person and every organisation has their own answer to these question. Everyone decides how to make the rules for contribution, how and who decides and what processes (if any) are needed to join these groups or how to contact them or make suggestions to them.
One typical way for many larger open source projects is a somewhat regular release schedule. This schedule and process often is agreed-upon by the core contributors or developers who then also do the associated work of preparing necessary patches and tests and collecting and addressing feedback from pre-release versions.
Especially for smaller projects you also often find a policy of "we release when its done" as the progress often depends on the availability of time of core contributors who might have other day jobs than maintaining a certain piece of open source software.
Other projects maintained and/or sponsored by large(r) corporations might have release schedules done according to whatever business plan or product launches need...
It really boils down to "ask the project".
However personally I found so far that it often becomes apparent when I got invested into a certain project, that I rather quickly learned who is responsible for what, and how releases do work; one learns it from feedback one gets from developers reviewing patches, from requests to do something first or a certain way, to ask for feedback from whomever or answers when one asks for how-to-do certain things in a project in order to do XYZ... It helps to hang out in the developers preferred communication platform and just curiously read who writes what (be that e-mail list, forum, IRC, discord, bug tracker, slack, rocket chat,... every project is different there). Read the commit logs.