What are the best practices for getting feedback on your game design from other developers?

The developers that should comment about the game design ideally have extensive experience on the genre, platform and market. Players point of view is essential for the success of a game but also the early involvement of developer with insight knowledge will help to identify pain points, bottlenecks and other technical issues that may lead to a possible redesign. That is the best scenario, resulting in a better, more polished product, not only improving the design but also easing the rest of the development cycle.

I'm genuinely annoyed by the default 'answer' given to this question. "Avoid people who are biased, rude, or vague, or who have conflicting interests or agendas." Who determines THAT? How do you know they are biased and you're not? We're not gods who get to decide what 'vague' means. If you have game design work and you need feedback, might be wise to ask people or devs who play that type of game. If they have design experience, that can help, but really what you want to do is find people who love that type of experience. And for heaven's sake do not go defining some people as 'rude' or with 'agendas'. That's a great way to leave a giant blindspot in your feedback model.

You also want to find people who are honest, constructive, and respectful, and who can communicate their feedback clearly and effectively. Avoid people who are biased, rude, or vague, or who have conflicting interests or agendas.

Look, you want to keep your game constantly prepared, absolutely. BUT, if you need feedback and the game is buggy, just explain the state to the people giving feedback. If there's something specific you want feedback on, you can certainly prep specific questions about the experience and design related to that, but I would also want to talk to some people very openly about what their overall experience was. If you bias people towards talking about a feature after making them interact with it, you might not realize nobody would use the feature without direction. So a better start might be to let people just experience the product and see what they do, or ask them to check it out after they haven't. Then you'll know if it's hard to find.

You also want to have a specific set of questions that you want to ask, based on the aspects of your game design that you want to test, validate, or improve. These questions should be open-ended, focused, and actionable, and avoid leading or loaded questions.

You can do it online or in person, synchronously or asynchronously, individually or in groups. Whatever method you choose, make sure you follow some basic guidelines.

So, one thing that can be really useful here: get a group of people together. You might still have someone being the facilitator or questioner, and this will certainly cause some amount of anchoring, but instead of asking questions of each person individually, have a group play it then watch them talk about it. The most valuable 'feedback' you get will still be the observation of how people moved and behaved, but a conversation among the people who played will make it highly subjective but also give you something rich to draw upon. As mentioned above, it's fine to have specific questions you want answered, just focus in on the experience. Too many people get vanity metrics like, "90% said they liked this" when that doesn't play out.

To ask feedback for a game does not necesarely mean that it's a finished or advanced product by any means. Once the development reach a state when you can transmit the core ideas of the game you can start gathering feedback using prototypes, if the testers are developers then they will understand this and give the opinions accordingly. In fact, the sooner you start getting feedback the better because the cost of refactoring things in the project es way less in terms of time, effort and money. The tests should provide a form to focus the objective of the feedback, otherwise you might not get the information about the elements you want and it's also much more straightforward for the ones giving feedback.

Bring the feedback back to the team making it. You might need to consolidate it and have some data/analyst expert types bring together themes effectively, but you want the feedback brought back to the devs doing the work. And again, this should include video or summaries of what people actually did when playing, not just what they said. The feedback is subjective, and your response will be too. That's ok. Don't expect this to solve everything in one shot. Also, don't overreact to feedback. One bad outlier session shouldn't be enough to derail you. Final little note: if you have no capacity to respond to the feedback you'll receive for whatever reason, don't waste everyone's time having a session.

you need to process and evaluate it carefully. Don't take it personally or defensively, but rather as an opportunity to learn and grow. Don't accept or reject feedback blindly, but rather weigh it against your own vision, goals, and data.

This should be ongoing. The team making the game should be interacting with or playtesting it regularly. People in the broader company (if that's a thing) should play it every so often. People outside the company should play as often as you can pull it off. You can do this too much, but that's more about your ability to internalize learning. I'd aim for having too much rather than too little, and focus on increasing the speed at which you can respond to feedback to solve the problems that emerge.

Remember we are all biased. And our experiences taint us in the way we are not even conscious about. Will Wright knew it when he was developing UI for The Sims to be universal, every week they were looking for a new group of individuals from outside company, from across the social spectrum, who never seen a game (or even did not play the games!) to see if game communicates what it meant to. When you take a controller, you are not even thinking twice if the left thumbstick is move, right one is camera, A is confirm, B is cancel. But what if you want to add novel control scheme that includes variety of meele and range attacks that combo together? That is what Bulletstorm tried to achieve, and failed as went against the biased "norm".