About this, when in doubt, ask the PR contributor. It should be ready after review and approval.
Normally, if a PR is reviewed and approved finally after applying the requested changes (if there are any), it’s eligible to be merged within 12-24 hours of the approval.
I think you should pick up relevant issues only (very important) and escalate them to the 3.7 milestone.
Can I assume that a PR created for merging a feature branch to master indicates that its owner thinks it is ready to be merged?
is there any indication in GitHub about how ready is a given PR to be merged?
Sometimes PR creators will mark the PR as a “draft” if they think it’s not ready; that’s perhaps the clearest and best indication.
Sometimes you can tell from the discussion whether the PR is a work in progress or ready for integration.
As @Pavl_G said, you can ask if you’re in doubt.
And of course the release manager has final say over what gets integrated.
I see this “Future release” label on some of the PRs. does it mean that this PR is approved for the next release?
Note that technically, it’s milestone, not a label.
The meaning of the “future release” milestone is context-dependent:
At the start of each release, the release manager creates a milestone for the release and moves issues and PRs to the new milestone. The new milestone helps everyone keep track of what’s in the new release.
Hi @adi.barda , thanks for putting your expertise into the engine development cycle. I am sure that with the help of the core members you will do a great job. I will support you in the testing phases of the alpha versions of the engine.
I would like to hear from @JhonKkk about the progress made in enhancing the rendering system. Are they completed? Will they be included in the next version?
Hi @capdevon , Thank you 
I really wanted but I was not able to reach JhonKkk . So I’m not sure about the possibility of his PRs integrating into v3.7.0
I have checked the repo from time to time, last commit was two months ago.
Yes I was checking pretty frequently too, as I was very excited for his PR. Lately I noticed he has created some other unrelated repositories on Github, so it is possible he has decided to move on to other things.
I can only speculate that the task became too burdensome when he was told to also refactor the engine to support future rendering pipelines in addition to his. But of course unless @JhonKkk returns then we can only speculate. Maybe he is only temporarily overwhelmed by the project and needed a break, but considering he hasn’t dropped in to update us or responded to messages, that seems unlikely.
I still stand by my point I made before, that the engine refactoring could have waited until we at least had our first new rendering pipleine added from his PR. At that point, a less experienced dev with less experience in writing rendering pipliens from scratch (like myself) could’ve taken on the task to do the refactoring later, after using his new pipleine and learning the code (just like many of us learned about PBR from using nehon’s implementation, and have since started contributing back and fixing bugs in it years afterwards). JME is currently so far behind engines like unreal graphically, and these changes could’ve narrowed the gap by a large margin. It is an absolute shame to think that we may have stifled this progress by overwhelming the contributor who has made the most progress on this and had a branch with it implemented into the engine with minimal invasiveness
I do not intend to rehash this debate, especially in this thread (however it feels relevant considering we all hoped that some form of his rendering pipeline would’ve made it into 3.7). So if anyone does want to reply, feel free to start up a new thread so we don’t derail this one, although I personally have no more to say that I haven’t already. I have no stake in the leadership or decision making anyways, so if those who are in leadership positions who make these internal decisions still feel that the correct decision was made, then so be it. I appreciate all of the contributors and core devs and I only give my constructive criticism because I care about the engine and want to see it do as best as possible.