It is our intention that our repository remains a useful tool for reporting and commenting on bugs, feature requests, and tasks for the Thunderbird community. No single contributor's work outweighs the importance of civility and professionalism in the Thunderbird community.
In order to keep our repository a useful, inclusive place we have guidelines which, by using this repository, you agree to follow. In addition, your participation on this repository is also subject to the Mozilla Community Participation Guidelines.
Violations of the Code of Conduct or the Mozilla Community Participation Guidelines are grounds for restrictions or bans on this repository.
- No abusing people. Constant and intense critique is one of the reasons we build great products. It's harder to fall into group-think if there is always a healthy amount of dissent. We want to encourage vibrant debate inside of the Thunderbird community, we want you to disagree with us, and we want you to effectively argue your case. However, we require that in the process, you criticize things, not people. Examples of things include: interfaces, algorithms, and schedules. Examples of people include: developers, designers, and users. Attacking or encouraging attacks on a person may result in you being banned from this organization.
- No obligation. "Open Source" is not the same as "the developers must do my bidding." Everyone here wants to help, but no one else has any obligation to fix the bugs you want fixed. Therefore, you should not act as if you expect someone to fix a bug by a particular date or release. Aggressive or repeated demands will not be received well and will almost certainly diminish the impact of and interest in your suggestions.
- No spam. Posting comment spam will lead to the ban of your account from our organization.
- No pointless comments. Limit comments on a bug to information which will help with resolving it. Unless requested, additional "I see this too" or "It works for me" comments are unnecessary. Constructive conversations unrelated to the topic of the bug should go in the appropriate discussion forum.
- No private email. Do not send comments on bugs by private email to users; no one else can read them if you do that, and they'll be missed and/or ignored. If an attachment is too big for GitHub, add a comment giving the file size and contents and ask what to do.
- No changing other people's bugs. Unless you are the bug assignee, please never change the label fields. If you notice any inconsistencies with the labels, do not change the fields of bugs you do not own and add a comment instead, suggesting the change.
- Accept decisions with grace. If another project contributor has marked a bug as Closed or Not Planned, then it is not planned. Filing another duplicate of it does not change this. Unless you have further evidence to support reopening a bug, do not post a comment arguing that a bug resolved as Closed or Not Planned should be reopened.
If you find a user violating the Code of Conduct or the Mozilla Community Participation Guidelines in comments on bugs, please report the bug to a core develoepr.
To report incidents follow the How to Report Violations of the Community Participation Guidelines.