We changed our privacy policy. Read more.
13

Closing them on sight should give a clear signal that asking in the wrong places is not appreciated. From there, it is possible to guide the users making an honest effort to look in the contributing.md file.


12

Open-source maintenance is often volunteer work. As a volunteer, you do not owe your time to anyone and can always say “no”. So it is absolutely legitimate to close any issue that is not comprehensible, ideally with a polite message in simple English that has a good chance of surviving machine translation. I would consider such a response to be more polite ...


12

Ultimately, if the developers are working on the project as a labor of love, they're going to work on what they want to work on. You can't expect them to prioritize your issue just because you asked them to. Instead, you can try to add incentives to make it more likely that your issue is one that they do want to work on. I can think of a few options, ...


9

Apsillers' answer is perfect, I will just add a case study about the last paragraph ("Money talks"). My open source project (1.5 million users) has had users pay third-party companies for features. I wrote the guidelines below, they are general enough to be applicable to most projects: Guidelines about sponsoring development In case you are willing to pay ...


6

When people start abusing your issue tracker to get support, then obviously your other support channels are not accessible enough. Make sure you have a separate support system which is both easy to find and easy to use. When I would have a problem with your software, a text file called contributing.md would not be the first place to look. In fact I would ...


5

In my eyes the best option is indeed the last option. You could use labels to indicate the language of the issue and encourage other people to translate these issues. Some issues can be translated by a machine, but others cannot. You don't want to miss out on the issues made in a foreign language. Denying all not English issues will give you less information ...


5

In the common workflow, issues are used to track the work that needs to be done on a given branch (usually master or main, but not necessarily). Once the fix is committed, there's no more work to be done on that branch, and the issue should be closed to signify it. Large projects with more diligent maintainers may also tag the issue to signify what release ...


4

I want help on ALL issues. Don't we all want help on everything? Actually, I don't. See my rationale below. Should I apply the label to the 200 open issues, and to all new ones (a few per day)? I am not sure this is worth it and tagging becomes useless when applied to all. It is probably a balance between the time taken applying the label, and the ...


4

It sounds like you need to provide an outlet - some acceptable place - for questions to be asked. That could be a mailing list, online group, IRC and so on.


4

As the question stands, the best option (of the three we're supposed to choose between) is: "Not Sufficient". There is, however, a follow-up question: What other criteria should be considered? The answer to this is: This depends on the project, the request and the maintainer's outlook. There comes a time when it is clear that a feature request is not ...


4

In my opinion - and I should stress it's only that - it's great that you've found a bug in a piece of free software. It's good to find bugs, because it makes software better. That said, if you report the bug, the maintainer is not obliged to fix it. If you fix it, the maintainer is not obliged to accept your fix. If your fix is accepted, you're not ...


4

Sonatype Jira for Issues: https://issues.sonatype.org/ Nexus OSS: https://github.com/sonatype/nexus-public JFrog Jira for issues: https://www.jfrog.com/jira Code on GitHub: https://github.com/jfrog


3

The WildFly project uses both JIRA (https://issues.jboss.org/projects/WFLY/issues) and GitHub (https://github.com/wildfly )


3

There are at least two competing interests in how open source maintainers run their projects: a desire to foster and accept outside contributions developer bandwidth Developers have limited time to review outside contributions, especially if the project isn't a full time job (but even if it is). Combine this with the occasional entitled user, and some open ...


3

You must also consider that what you consider an important bug might be very low priority for the developers (for whatever reason). Yes, there have been cases where blatant security problems were dismissed as "irrelevant". In the end, you'll have to make your own call. See if you can fix the bug, band together with other users willing to chip in, get more ...


2

On Github, you can use issue templates. These templates are shown to users while they open an issue, which means that a simple warning like Please don't ask questions here, but use https://example.com is presented to all users, even if they didn't check the repository wiki or readme.


2

We allow anyone to open an issue and make feature requests. We try very hard to respond to actual issues quickly, but obviously can't always fix everything. Bugs are bugs, but feature requests are the killer. We get a ton of really interesting feature requests. Unfortunately, most of them are either barely related to what our project does, or simply too ...


1

jfrog is another one, they have OSS projects on GitHub: https://github.com/jfrog But they use Jira for issues: https://www.jfrog.com/jira


1

Short answer (and not too useful): it is your project, given as a gift to the world. You can do as you please. Here "you" is generically the group actively participating in development. You should set up some guidelines (the ones you outline in the question look fine to me), and perhaps publish them. Just make sure that nobody feels entitled to have their ...


Only top voted, non community-wiki answers of a minimum length are eligible