How are open issues prioritized for upcoming releases?


I’ve been wandering around the project roadmap and around the different github repositories within the OpenSearch project. There are few examples of open issues, either enhancements or bugs, that have taken quite some popularity (i.e. they are requested by multiple people).

On the project roadmap activity, I see a number of people that actually assign/edit/move things around. Is there any internal process that defines which issues will make it on the upcoming releases? Are the open issues along OpenSearch repos and their popularity somehow taken into account during that process?



Hi Sokratis, it’s a combination of how popular/in-demand a feature is, the scoping estimates for how long something will take to build, and when folks are available to work on it. Most of the time when something moves, it’s for one of the last two reasons. Either we learned something new that affected the scoping estimate, or engineers turned out to be more or less available than we had originally thought. As I’m sure you can imagine for a project of this size, an engineer with deep expertise in one area wouldn’t simply hop over to another part of the codebase without expecting to lose some productivity, so most schedule revisions are made “locally” by the group of people collaborating in an area of the codebase. That’s probably why you see a lot of names there.

As far as determining which features are most in-demand and therefore highest priority, the largest factor by far is what people are asking for through mechanisms like forum threads, GitHub issues, and community meetings. Everyone working on the project wants to build software that’s really useful, so direct conversation with people who are using or want to use OpenSearch is unbelievably valuable.