<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">The open bug tracker is a <b class="">huge</b> improvement over radar. (Thanks folks!!!!!!!) However, I feel like there are things I don't understand quite yet that would make me into a better bug reporting citizen. Obviously, the "every project" stuff like "how to write reproduction steps" I already know. But there's a class of project-specific information that people have to grasp to be effective, and I feel like there are some gaps in my knowledge. And probably other users as well.<div class=""><div class=""><br class=""></div><div class="">It may be appropriate to write a "So, you're affected by a Swift bug..." guide on <a href="http://swift.org" class="">swift.org</a> with the goal of growing people from the "ground floor" to being productive members of society. I volunteer to draft such a thing, if someone can fill in the gaps for me, but it may or may not be more effective to have someone who already knows the answers write it up.</div><div class=""><br class=""></div><div class="">I propose an outline like:</div><div class=""><br class=""></div><div class="">1. Should I file a bug?</div><div class=""><br class=""></div><div class="">It surprises some project newcomers that the bugtracker is not an effective place to discuss language improvements.</div><div class=""><br class=""></div><div class="">For those of us who have mastered that (potentially nonintuitive) concept, there remain a set of corner cases. For example, I recently opened a "bug" because I can't link the Swift static library on Linux. The resolution is probably to add one or more flags to swiftc. Is that more of an "enhancement"? Are "enhancements to tooling" better fit for a mailing list? I don't know, so I kind of just "go by feel", which may or may not create more work for the core team later.</div><div class=""><br class=""></div><div class="">More broadly, there may be bugs that "everyone already knows about" and that filing is mostly noise. I sometimes feel like I wander into that department, but I'm not totally sure... This especially occurs with the non-Swift satellite projects that are "greenfield" in nature, because at present, things are mostly unimplemented, and merely listing that does not add a lot of information, perhaps.</div><div class=""><br class=""></div><div class="">2. If I found a bug that is at least superficially similar to my problem, what should I do?</div><div class=""><br class=""></div><div class="">Options here include: Vote, watch, leave a comment, edit the description, file a duplicate. Buried in here is the problem that I don't know how what kinds of actions might affect a bug's priority (if any) so it is not clear to me how to register a "me too" in an situationally-appropriate way.</div><div class=""><br class=""></div><div class="">3. How should I (if I should) use the components/labels?</div><div class=""><br class=""></div><div class="">I have worked out pretty good guesses of what they mean based on what the bug triagers are doing. It may or may not be appropriate for me to apply labels/components to my bugs or those I see others filing. It may or may not be appropriate to write down what they mean in some official place so that folks can apply labels themselves and reduce triaging work.</div><div class=""><br class=""></div><div class="">4. How should I (if I should) describe the pain of a bug?</div><div class=""><br class=""></div><div class="">The bugs I file vary a lot on the "pain scale": from "I can work around this easily" to "this is significant enough that I am debating PRing this and it may be productive for a core member to outline a mergeable solution" to "I cannot continue to work until this problem is resolved and so I am applying a fix to my tree in the other tab right now"</div><div class=""><br class=""></div><div class="">Options here include things like the priority field (although it doesn't scale to multiple reporters), leaving a comment, etc.</div><div class=""><br class=""></div><div class="">Obviously, reporters shouldn't expect the core team to work on their schedules, but siphoning off the "I'm severely affected!" information to a predefined location may be useful in terms of getting that out of the comment feed, helping to prioritize work, etc. It may also be useful for those of us on the outside to coordinate our work better with each other, as if there are several of us motivated to fix it, we might band together and fix it ourselves.</div><div class=""><br class=""></div><div class="">5. How should I notify people I think should be aware of the bug?</div><div class=""><br class=""></div><div class="">Often I look through git blame and can find a person "associated" with the bug, either because they actually introduced it or because they seem responsible for the general area. If i ping them in the comment thread, very often they chime in with helpful information / workaround / proposed solution / follow-up questions, although sometimes they sound annoyed (which may just be the medium).</div><div class=""><br class=""></div><div class="">I avoid assigning bugs to people, because, well, they don't work for me.</div><div class=""><br class=""></div><div class="">I don't really know if any of those behaviors are "the right thing to do", and I feel like if somebody set expectations about how to politely and effectively "bring someone into the thread who might have good insight into the situation" that might reduce potential conflict.</div><div class=""><br class=""></div><div class="">Also, thanks again for an open bug tracker, it makes an enormous difference in my day-to-day life. I just feel like with a little more handholding we could make it an even more effective tool than it already is.</div><div class=""><br class=""></div><div class="">Drew</div></div></body></html>