Figuring out the future is tricky business. We all know the internet is not always a friendly place. We want this discussion to be different.
Writing a "status quo" or "shiny future" story is an act of bravery and vulnerability. In the status quo, we are asking people to talk about the things that they or others found hard, to admit that they had trouble figuring something out. In the case of the shiny future, we're asking people to put out half-baked ideas so that we can find the seeds that will grow into something amazing. It doesn't take much to make that go wrong.
“Most people do not listen with the intent to understand; they listen with the intent to reply.”
The golden rule is that when you leave a comment, you are looking to understand or improve the story.
For status quo stories, remember that these are true stories about people's experiences -- they can't be wrong (though they could be inaccurate). It may be that somebody tries for days to solve a problem that would've been easy if they had just known to call a particular method. That story is not wrong, it's an opportunity to write a shiny future story in which you explain how they would've learned about that method, or perhaps about how that method would become unnecessary.
For shiny future stories, even if you don't like the idea, you should ask comments with the goal of better understanding what the author likes about it. Understanding that may give you an idea for how to get those same benefits in a way that you are happier with. It's also valid to encourage the author to elaborate on the impact their story will have on different characters.
Remember, opening your own PR is free (In fact, we're giving an award for being "most prolific"). If you find that you had a really different experience than a status quo story, or you have a different idea for a shiny future, consider just writing your own PR instead of commenting negatively on someone else's. The goal of the brainstorming phase is to put a lot of alternatives, so that we can look for opportunities to combine them and make something with the best of both.
Here are some examples of good questions for "status quo" stories:
- Tell me more about this step. What led NAME to do X?
- What do you think OTHER_NAME would have done here?
- Can you be more specific about this point? What library did they use?
Here are some examples of good questions for "shiny future" stories:
- How does NAME do X in this future?
- It seems like this would interfere with X, which is important for application A. How would NAME handle that case in this future?
You should not be afraid to raise technical concerns -- we need to have a robust technical discussion! But do so in a way that leaves room to find an answer that satisfies both of you.