Improve community experience

Interacted with many communities over the years, unfortunately my first interaction with this community didn't make the best first impression.

Hopefully maintainers are aware of Github's community guidelines, in particular 'Building a strong community'.

As a new member of the Python community trying to find my way around I politely asked a question hoping to gain some context around this project; the issue was closed abruptly without explanation; I was surprised but no problem; then I received an explanation ending "It's not our job to explain that to you in this issue." and the issue was locked, I'm sorry they feel that way, our work should be enjoyable.

I didn't feel much empathy, welcomed, or the general tone to be in the spirit of the community guidelines. As such I've taken the time to raise this issue to offer some constructive feedback in the hopes of improving the situation. The end goals being to: encourage participation; make new members, like myself and others, feel welcome; and increase contributions, including improving the Readme, FAQs, etc, which would deal with issues like mine before they're even raised.

Obviously I don't have much experience with your project but I do have a lot of appreciation for open source and enjoy contributing where I can.

Thank you 🙂

Since I believe I'm involved in this I'll address it.

We're a fairly popular open source project and we get a very large volume of issues of variable quality. I closed your issue in particular for several reasons:

I believed the original query was resolved (does pyflakes lint for missing dependencies) -- I had answered the query with reasoning that is echoed in the description / README of the project
The question itself showed little to no research, you could very easily verify that pyflakes in fact does not validate missing packages (in fact, it seems you already knew this from your issue description)
The followup question was off topic for the issue tracker
There was no documentation or FAQ to improve as the information is already there

The followup question about comparing tools is an exhausting one, and admittedly I should have probably commented something to the effect of "please read the descriptions of the tools in their documentation" or "please do some research" while closing it. There is quite the plethora of information on the topic online and I'm sorry but we really don't have time to generate novel blog post content in an issue tracker for individuals who already have access to this information but decided not to use some basic searching tools. Additionally there are tens to hundreds of different linting / formatting / validation tools in the python ecosystem and comparing each and every one of them would not be a great use of anyone's time. The individual projects themselves should be responsible for producing information about the tools themselves as well as their goals.

If you took the time to read the README, your question is addressed in the third sentence:

A simple program which checks Python source files for errors.

Pyflakes analyzes programs and detects various errors. It works by parsing the source file, not importing it, so it is safe to use on modules with side effects. It's also much faster.

I agree that improving contribution from outside is a positive goal, but you've also gotta show an ounce of empathy for maintainers. We're building this software entirely for free. If you want to show some support please consider sponsoring some of the people that put in hard work on these tools instead of demanding.

And finally, the reason your issue was locked (I believe, I wasn't the one who locked it) was because you were being directly disrespectful:

Insightful 😄 No problem, I'll figure it out.

Disclosure: I can't speak for this project, its maintainers, or its community. I've only made one small contribution to pyflakes. I also may be feeding a troll.

From what I can see, there is no issue with your interaction. Let's look at your statements and the facts:

I politely asked a question hoping to gain some context around this project

Ok.

the issue was closed abruptly without explanation

This is not true. @asottile took the time to read your question, interpret it (which was not trivial, since it was ambiguous), and respond to it. He then informed you that "no pyflakes can't / shouldn't do that it is a static analysis tool not a dynamic one", informing you that detecting missing dependencies is outside the scope of this project. Addressing your question and the GitHub issue that went with it, he closed the issue.

You did use the same GitHub issue for a different matter: to then ask for a comparison between flake8/pyflakes and pylint. Can this question be asked? Yes. Is it in scope of the issue you raised and @asottile closed? No. Is this question almost certainly answered elsewhere? Yes. Did you search for an existing answer before requesting someone take the time to write you their perspective? This is debatable. You did provide one article URL, though you did admit you sped read it.

From a search engine search I took the time to perform and analyze, the top results alone provide ample discussion on your second question: https://www.reddit.com/r/Python/comments/82hgzm/any_advantages_of_flake8_over_pylint/ and https://stackoverflow.com/questions/1428872/pylint-pychecker-or-pyflakes provide some good perspectives, and those are only 2 of 2 results I examined.

You could possibly open a separate issue for such a question (though I can't guarantee it wouldn't be closed for being already addressed elsewhere), but if you still seek a more comprehensive answer, I would choose to instead compare the projects' documentation, or examine more thoroughly the material that already exists on the web.

You also stated:

it would be helpful

No problem, I'll figure it out.

which now also seem to be untrue, given your new issue. It's apparent that information would not have just been helpful, like a nice-to-have. It now seems like that information was a requirement made to the project (maintainers, or specifically @asottile) by you, and the fact that it was left unanswered in that issue was problematic to you. Again, contrary to you stating it was no problem.

I should also point out that while you use terms and phrases that seem innocent, from my perspective, you seem to be rather hostile. In addition to the untrue statements made, which alone can be very damaging to a person or a project in general, you decided to make public a case against the current functioning of the project, by way of raising issue against a single perceived slight. There's quite more to this, but that's all I will say on this.

As a general statement, I'll take the time to say: I think everyone should be aware of what open source is: gifts from the givers. If we hold dear the golden rule, which I think everyone should do at all times, we wouldn't be quick to make demands of those who choose to share their lives' work with us, and we'd be more grateful for what we already have.

Adding my own voice to the matter, I should state that I've felt very welcomed by this project's maintainers, and have seen no issue with its community. They guided me through my very first pull request on GitHub. I make no demands of them, and I'm grateful of the contributions that @asottile and others have made, and what they've shared with us.

I can see how the terse replies to your question could seem unwelcoming. But I would also point out that a good issue is one that has a clear focus. For example, describing a bug (or unexpected behavior) with clear steps for reproducing the issue. Or a clear enhancement request. Or a proposal for filling a gap in the documentation. Issues that boil down to "I don't really know much about Python or this tool, could someone please spend lots of time educating me" are time sinks. Especially since they tend to wander in random directions as the person who opened the issue keeps thinking up new question. It's not reasonable to expect people who are maintaining a tool in their free time (which is the case for the vast majority of open source projects) to spend lots of time educating people.

As the other person involved in that issue, @asottile maintains far more packages than I ever did. I used to maintain far more than I do now (in the Python community) but I still maintain a fair number which are widely used and otherwise considered "popular".

I'm happy to work on real issues. The questions you asked, however, are best suited to a question and answer forum like StackOverflow.

By way of comparison, your interaction with the project felt as if it was taking for granted our time, attention, and acutely prioritized your time over ours (you said you didn't read something very closely and you wanted us to give you all the answers). Further your follow-up to Anthony's response seemed sarcastic and unappreciative. That behaviour feeds into an archetype that anyone who has maintained even 1 project of any note has experienced - the entitled user. You checked several of the boxes and I wasn't going to continue wasting my attention span or Anthony's on your entitlement. I spend less and less time these days writing code and trying to take the mental overhead of dealing with users exhibiting this behaviour off the plates of others.

To reinforce the core point: There are places (e.g., StackOverflow) for your questions and there are people who would be happy to answer your questions. This is not the place. We are not the people.

The only thing that I can say about this "issue" with respect to @nomasprime is: Please consider contributing to the project if you really think that your idea is valuable. It is always better to show an example (implementation) of your idea, than just to talk about what is a good idea and so on. Also you should appreciate the time that others put into those projects.

To use and engage with an open source project, in my opinion is privilege - not only you have it for free, but you also have people that keep the project alive (in shape) for the benefit of everyone. And if you try to bother the maintainers with unrelated issues (that are not bugs), at some point the maintainers may decide that it's not worth it to keep maintaining that specific project. And at this point you may not even get an answer. It will be ignored, which I believe is worse than getting any kind of answer.

But at the same time you also have the power to fork the project and implement your own ideas. And you can show those ideas to everyone, and if others appreciate your ideas, they can use your fork instead :) No one can stop you from doing this.

I hope that @nomasprime will understand us - we just want to explain how most OSS projects work. And if we value each others time, our community experience will be better :)

@int3l I appreciate your perspective. At this point, I think enough people have responded here attempting to defend Anthony and myself. I'd ask others coming to this issue to not pile on at this point because I'd like @nomasprime to have the opportunity to respond. If folks insist on piling on, I'm happy to lock the issue.

I have to say, when I originally saw https://github.com/PyCQA/pyflakes/issues/556, I was a bit disappointed by the responses. The quip in particular, "It's not our job to explain that to you in this issue." I personally find to be toxic. I noticed that pyflakes doesn't seem to have a code of conduct. If it did have one, or at least of the ones I usually see in projects I contribute to, this response, in addition to locking the issue to shut down any further responses, would be flatly in violation of it.

However, having seen this issue, I am now extremely disappointed. I've already seen bad behavior from people in this community in other places, some of which I have called out, but I have been hopeful that people could improve. But here, I see someone trying to get this community to be more welcoming, and instead of taking this opportunity to to learn and improve behaviors, the people have have turned defensive and tried to turned it around back on the accuser. I understand that it's natural to see such things as an attack that should be defended against, but I really encourage everyone who has commented here to see this as a non-attack and to take a moment to introspect how they can be improved.

I really hope this community can improve itself. I really like pyflakes as a tool, and I occasionally like to participate in its development, and I would really hate to see it stop being usable due to a community which is not safe to participate in.

The quip in particular, "It's not our job to explain that to you in this issue." I personally find to be toxic. I noticed that pyflakes doesn't seem to have a code of conduct. If it did have one, or at least of the ones I usually see in projects I contribute to, this response, in addition to locking the issue to shut down any further responses, would be flatly in violation of it.

Given you called me out specifically, and you're asking for changes in behaviour, I'd ask you to be specific about what changes you think should be made. Was I too blunt? Should I have spent several hours listing out the differences? What should I have done differently? You want the community to improve, that's great. You can't say, however, "Go forth and improve" without giving clear and actionable feedback on how to do so.

A few counterpoints, @asmeurer, from an outsider and newbie in the open source community, to what I see as the meat of your post. Let's make sure we know and examine the facts, and within context:

@nomasprime opened an issue with a question, basically asking if pyflakes can warn users of missing dependencies. That's a fair question. And a maintainer took the time to answer that question, including providing additional help to @nomasprime, by describing what he/she sought answered in more accurate terms. And I'll add that it was answered promptly.

@nomasprime then used the same GitHub issue to request a general comparison between flake8/pyflakes and another tool. This was irrelevant to the issue at hand. The issue being resolved, the issue was closed.

@nomasprime then acknowledged this and said "No problem".

Then another member added even more helpful information relevant to the original issue. Good little nuggets of information, honestly. Most of it was in fact news to me. That member then also informed @nomasprime that the second question asked in the issue would not be explained /in this issue/, because it was irrelevant to the issue.

That was it. The issue opened was resolved, and discussion was closed.

Except, of course, it didn't end there.

Two days later, @nomasprime created an issue that, among other statements, roughly requested that the 'community experience be improved' (paraphrasing), based on this interaction.

Those are the facts. That is what has led us to here.

So, let's take a look at it.

What was declared "No problem" by @nomasprime was made into a problem by @nomasprime --an issue actually, but not one for his/her second question. The main complaint of the second GitHub issue was that @nomasprime believed his/her first issue was "closed abruptly without explanation." I've established that this is false, both in my earlier comment and through the exposition above. This was the reason for the proposed "community (experience) improvement."

From this one interaction--this one interaction, where a question is posted on the internet, is answered within minutes, and additional relevant information is provided, with no detectable malice whatsoever present--it was then concluded that the "community experience" should be improved.

To be frank, this action is absurd, among other things. And because an off-topic question was plainly told it would not be answered in that GitHub issue? Strangers take the time out of their lives to answer a question and provide relevant information to you (generally speaking), and someone has the gall to raise an issue with it because they didn't do more for them, or didn't do it precisely in a way that satisfied them? In my opinion, those who responded to the original issue did what they should have, were they going to address the issue at all (which they didn't have to--lest we forget): they saw it, analyzed it, and answered it directly, providing additional information for @nomasprime and the rest of the pyflakes community. They also moderated the forum, to keep it on-topic, which is absolutely their right, and almost certainly their responsibility (if it's possible to fulfill), given that clear, direct, and organized discussion makes for great project documentation that can be used by other users to search and explore--especially when there are no bodies who regularly fill the role of documenter in a more traditional sense.

Here's a general proposal I think many would (and do) follow, in case they find themselves in a similar situation: a proper course of action would be to genuinely thank them for the relevant knowledge they've shared, and if you still have unrelated questions, consider creating a separate issue, or better yet--now that I bring up searching existing material instead of asking questions that have already been addressed--before you create a new issue: take some of your own time to do thorough research until you satisfy yourself. I suppose I must also explicitly state that I am being sincere here, and mean no malice to anyone: this is an actual actionable proposal for improvement (for anyone who doesn't already do it), that anyone can follow--today.

This is a proposal I myself follow, and I know plenty of others follow it as well, but I know that some don't. So if there's an improvement to be made, I think that's a great one. And it goes without saying that you're not the devil if you occasionally slip up there. But what I find absurd, among other things, is a request that the "community experience" must be improved, given what actually transpired.

@asmeurer: I won't speak for others, although they've all raised good points that should earnestly be reflected upon, so: you may say or even think I've been defensive, but the majority of what I've discussed are simply the facts, including exposing falsehoods, and stating how some behaviors are at odds with the facts.

I would encourage everyone to always seek to improve themselves in general (Note: I also see such broad statements as ineffectual, if intended politely, due to being unactionable), but I see what's presented here as a non-issue, given what led up to it. (Particularly so because I consider the obvious desire and willingness of the project members to help others, and do not sense bad intent or "toxicity" in what's they've shared.) And I see what has come after it, by the other project contributors and members, as valuable free expressions, which include aspects and insights I have not considered. Do not simply dismiss what they've shared as being "defensive." That's something I honestly consider deeply demeaning, particularly given the attention they've given this, as evident by their responses, which is more than I would have asked for.

Ultimately, a large part of what's really being discussed here is: what we demand of people who share freely and with good intent. I believe there are too many among us who demand too much from some others. I also believe it's too easy to demand "just a little more" from others. It easily becomes a refrain with no end, cut by cut. But the truth is there's only so much we can do, so much energy we can spend, and only so much time in the days of our lives. We must prioritize. And from the various writings I've read over the years from open source developers, clearly too much is being demanded already. And without more direct, honest, and considerate suggestions, any demand for "improvement" is indistinguishable from the crack of a whip.

What's clear to me is who has a positive impact on the community, and I'm grateful for this project's members, and I hope they continue to share their creations and knowledge. (We should be so "lucky" that there are those among us who do this and wish to help, so willingly.) That's what established this community, and what sustains it.

I do wish to extend a welcome to @nomasprime. The Python Community in general is quite welcoming. In fact, most of people you have already interacted with are indeed wonderful, talented and respectful people.

We have a lovely community of contributors that believe in Python and maintaining workflows related to it. While time and resources are limited at bringing newcomers up to speed on specific projects, your helpful contributions are welcome (e.g. researched ideas and complete PRs). Issues/PRs that progress a project and assist the maintainers are a big plus.

Take care.

First off, I want to make it clear that I don't speak for @nomasprime. Everything I say is just my view of things. It is relevant though, I think, because the way I see the maintainers interact with others affects how much I want to participate in this community, and it would presumably have the same effect on others (even if they don't speak out as I do).

Given you called me out specifically, and you're asking for changes in behaviour, I'd ask you to be specific about what changes you think should be made. Was I too blunt? Should I have spent several hours listing out the differences? What should I have done differently? You want the community to improve, that's great. You can't say, however, "Go forth and improve" without giving clear and actionable feedback on how to do so.

I'm not really sure how to be more specific. I already listed the things I see that I think should have been done better:

The phrase "It's not our job to explain that to you in this issue." is rude and adds nothing to the conversation. Everyone here seems to be focused on whether certain things add or take away from the time of people. Well, I think it applies both ways. If someone asks a question and you have a response that doesn't actually answer the question, that doesn't add anything useful to the conversation. If you don't want to answer someone's question, then don't answer it. But rude/snide remarks not only waste your time, but they also waste the asker's time because they don't actually help in any way.
Locking the issue (note, I don't actually know who locked the issue. Since @sigmavirus24 was the last commenter I presume it was him. If it was not, then I apologize. Even if it wasn't though, you already threatened to lock this issue, so I think this is relevant regardless). Locking the issue very explicitly closes down the community. It sends a very clear message that the person who opened the issue is not welcome, especially when no further reasons are given for the lock. Frankly, I would almost never lock issues. It is an extremely unwelcoming practice. The primary usage of the lock button is to protect issues that have received unwarranted outside attention (we all know the sorts of viral issues on GitHub this applies to, but they are extremely rare in the grand scheme of things).
On this issue, everyone has been focused on what @nomasprime did wrong, and how they should improve. Even though the very point of the issue was how the core maintainers should improve, I see very little introspection on how that can happen.

All the responses on this issue are implying to me that @nomasprime somehow "deserves" the treatment he got because he didn't fully respect the maintainer's time (and, again, if that's how I interpreted it then I'm sure many others will too). A community where the expectation is that maintainers will be rude to you unless you surpass a sufficient bar of gratitude (or whatever) is not a community I want to be involved in. You should never be rude to someone, even if they are rude to you (which from my point of view @nomasprime wasn't, but that's irrelevant).

Finally, I want to point out a bit of hypocrisy. Everyone here seems to think that "Insightful 😄 No problem, I'll figure it out." was a rude response from @nomasprime. I personally don't really see it as that. I especially don't see how it could rude, but things like "It's not our job to explain that to you in this issue." as not. Is it interpreted as sarcasm? To me, a good faith interpretation of it is as meaning what it literally says, which is not rude in any way (it even has an emoji to help convey the emotional content). Maybe @nomasprime can confirm whether or not it was intended as a sarcastic quip. Yes, it was a rather short response, which leaves it open to interpretation. But as @krader1961 pointed out, things should not be automatically thought of as rude just because they are terse, at least in open source.

* The phrase "It's not our job to explain that to you in this issue." is rude and adds nothing to the conversation. Everyone here seems to be focused on whether certain things add or take away from the time of people. Well, I think it applies both ways. If someone asks a question and you have a response that doesn't actually answer the question, that doesn't add anything useful to the conversation. If you don't want to answer someone's question, then don't answer it. But rude/snide remarks not only waste your time, but they also waste the asker's time because they don't actually help in any way.

I take it that perhaps I was overly blunt and can work on that. How better can I point out that someone's engaging the community in the wrong place?

* Locking the issue (note, I don't actually know who locked the issue. Since @sigmavirus24 was the last commenter I presume it was him. If it was not, then I apologize. Even if it wasn't though, you already threatened to lock this issue, so I think this is relevant regardless).

It was me. I've always found it ridiculous that GitHub doesn't let an organization be transparent about that. As for locking down this issue, there are (in my opinion) too many people participating whose opinions are valuable but creating an echo chamber and I don't want those echos drowning out the signal that might otherwise be extracted to actually make the community better. That's why I "threatened" to lock this. I don't think a pile-on of Nomasprime makes sense. It's the same kind of community management but on a smaller scale. Trying to give feedback and being piled on is still just as disheartening and disappointing as the "viral" issues you mention later.

Locking the issue very explicitly closes down the community. It sends a very clear message that the person who opened the issue is not welcome, especially when no further reasons are given for the lock. Frankly, I would almost never lock issues. It is an extremely unwelcoming practice.

I disagree entirely, but it's a matter of opinion. There's "reasons" for locking an issue including "Resolved" indicating this isn't a tool to "shutdown" the community. It's a tool to manage issues. If you look at projects like Requests, those issues should be more aggressively locked because the number of years-old issues that people comment on with completely different and unrelated problems is infuriating to the ~1500 people receiving notifications.

The primary usage of the lock button is to protect issues that have received unwarranted outside attention (we all know the sorts of viral issues on GitHub this applies to, but they are extremely rare in the grand scheme of things).

Again, I disagree, but there's no need to nitpick over the usage of a tool that is available.

But as @krader1961 pointed out, things should not be automatically thought of as rude just because they are terse, at least in open source.

Finally, we end on hypocrisy. You extend Nomas Prime a different interpretation than me. I'm going to try to be less terse but that's not the feedback you've actually given me. All you've done is say "No. Bad. Go away." without saying "Try doing X in this different way next time".

A charitable read of your feedback is "Stop being blunt" a less charitable read is "Stop defending your own time". That said, being blunt is one way of defending my time. To be more verbose is to spend more time and energy. If maintainers don't defend their time and energy, they burn out. If maintainers are too terse, they risk making the community feel exclusive. Each maintainer has to find a balance there. Perhaps your balance, @asmeurer, is different than mine. That doesn't give you the moral high ground as you seem to take here. Other folks here seem to have a balance closer to mine but that doesn't make me right either. That's why I'm trying to meet you and ask for actionable improvements beyond "don't do that".

Here's an alternative comment that wouldn't have been rude/unwelcoming:

@nomasprime No pyflakes won't inspect your site-packages to determine if you've not installed something. That's why it's faster. There are extensions to Flake8 that will do that though. Flake8, however, uses itself and pylint for linting. Both tools are useful and have some overlap but have far more things that the other does well.

Followed by not locking the issue.

Note that this is identical to your comment sans the last sentence. So you would have said/done fewer things. This is why I don't understand the comments about time. This would have taken less time. If you are really strapped for time, you could have not commented at all, since everything you said was already mentioned in Anthony's comment.

And in general, take things in good faith. Don't assume that statements like "Insightful 😄 No problem, I'll figure it out." are necessarily rude/sarcastic. If it isn't clear, ask for clarification. One could also say the same about your statement, but the locking of the issue really seals the deal.

If you look at projects like Requests, those issues should be more aggressively locked because the number of years-old issues that people comment on with completely different and unrelated problems is infuriating to the ~1500 people receiving notifications.

Even if you maintain that large projects like Requests have a valid use-case for wide use of the lock hammer (which I disagree with, but that's irrelevant), 1) pyflakes is not a large project, and 2) the issue in question is not "years-old issue that people commented on with different and unrelated problems".

Locking an issue prevents anyone else from responding. It enforces whatever you said as the "last word" on the subject. It also enables a echo chamber where you'll rarely hear people complain about an issue being locked because they can't (because the issue is locked). Whatever your actual reasons for locking may be, the optics of it are very bad (and not indicating in the comment why you are locking makes that worse). And locking this issue in particular would have particularly bad optics.

I have some thoughts on your most recent post, @asmeurer:

Here's an alternative comment that wouldn't have been rude/unwelcoming

I disagree with the interpretation that that comment was rude: I interpreted it as concise and direct, which I can appreciate (and if the sentence were directed at me, I would then consider opening a new issue, or doing further research; I would not assume the person who just gave me helpful information was rude). But I think it's wrong to state that the comment was "unwelcoming": you're referring to a comment that provides additional information to the question raised in the issue. Even after someone else had provided an answer to the question, another person decides to provide another perspective with more helpful information to the asker on the issue. There's nothing unwelcoming about that. Even if you interpret the last sentence as being rude (which I personally find jarring, given that the person had freely shared useful information in the comment's preceding sentences), you cannot deny the act of an individual answering the asker's opened issue and sharing more relevant information is very welcoming.

And this is related to what I consider an important misconception you have: You said that the last sentence (and sentences like it)

adds nothing to the conversation.

doesn't add anything useful to the conversation

don't actually help in any way.

These are not true. It's additional information: it's a response to the question asker's second (off-topic) question, which you admit you would rather have ignored (discussed below), and it informs the asker that /that issue/ is not the place for the unrelated question. This is a strong hint that another GitHub issue could be opened for the separate matter. (Though again, considering the specifics, I cannot guarantee the outcome of such an issue)

This sentence is also a strong hint (and to myself, a clear reason) for why the issue was locked: off-topic discussion had begun in an issue that was resolved, so in order to prevent further off-topic discussion from taking place (and all of the extra energy and time it can lead to--which should require moderation at some point, anyway), it was locked.

Note that this is identical to your comment sans the last sentence. So you would have said/done fewer things.

What I stated above is also important because you've stated that it was "not indicat[ed] in the comment why you are locking" the issue. The last sentence in the issue's second helpful comment makes it clear to me. And to not include that sentence, like you suggest, would be to not include more information on why the issue was locked.

Also the choice to deliberately ignore the asker's second (unrelated) question, instead of address it concisely and directly, does not seem "welcoming" at all to me. I'm unsure why that is your preference. That question could have easily remained unaddressed indefinitely. Certainly no one would answer it (or even see it) if they were looking through issues that were created specifically for such a question. And as a member of the community, deliberately not addressing a question I had when someone easily could have (even if it was to tell me that the current thread was not the appropriate place for such a question / that it would not receive an answer in the current thread) would be very unwelcoming. I would always prefer my question to be addressed, instead of waiting potentially definitely for a response, when others know that that issue is not the place for that question. At least that way, I can take the appropriate action to create a new issue relevant to my new question, or perform additional research myself, and I can do so right after receiving that information.

This is why I don't understand the comments about time. This would have taken less time.

I think this is short-sighted. The time saved by not typing that one sentence is minute, of course. And it seems plain to me greatly outweighed by the time that could be required from a resolved issue left open longer than necessary, notably after it had already started to go off-topic. I think this is a very good reason for locking the issue and the inclusion of that last sentence, over preferring to ignore the off-topic question and leaving the resolved issue open. There is no benefit to having off-topic discussion under the thread of one issue when it could/should take place in another. This helps those who take the time to search through such issues for whatever they seek. Knowing that an issue contains discussion relevant to that issue and not off-topic material is very helpful to the community. Moreover, knowing that discussion relevant to an issue won't be found in some unrelated issue can also be very helpful to the community. This is good practice.

If you are really strapped for time, you could have not commented at all, since everything you said was already mentioned in Anthony's comment.

This is clearly not true: @sigmavirus24 provided additional helpful information, particularly for me (and others in the community), which I've already made clear.

And in general, take things in good faith.

@sigmavirus24 made a good point about (your) hypocrisy here, which you seem to not see. You encouraged everyone to engage introspection before: Truly, take the time now to do the same. This is relevant to the discussion: you bring up points that you might not be making, after introspection.

Don't assume that statements like "Insightful 😄 No problem, I'll figure it out." are necessarily rude/sarcastic.

This seems a very charitable interpretation of that statement.

I'll reveal my own interpretation on "Insightful 😄". Again it helps to reduce confusion by looking at the true sequence of events: 0.) After the issue's question had been answered, 1.) an unrelated question was then asked by the issue creator in that issue's thread, 2.) the issue (the relevant question) being resolved, the issue was closed, 3.) the follow-up to the close of the resolved issue--and not answering in that issue an unrelated question--was: "Insightful 😄". I've engaged in enough social behavior. I don't know a person who wouldn't honestly see that that's a sarcastic statement. I also see it as rude to make such a sarcastic statement to someone who helped you. (Speaking generally, How do you treat the people who provide you with what you ask for? Do you see how much more you can get out of them, and then deride them when they stop? I sincerely hope none of us do this, but we are faced with the truth that people like this exist.)

Even if you maintain that large projects like Requests have a valid use-case for wide use of the lock hammer (which I disagree with, but that's irrelevant), 1) pyflakes is not a large project

The size of a project is irrelevant to following good practices (eg. for moderation, documentation). Valid use cases are valid use cases, regardless of the size of a project.

and 2) the issue in question is not "years-old issue that people commented on with different and unrelated problems".

This is addressed in the paragraph I wrote above, starting with "I think this is short-sighted."

Locking an issue prevents anyone else from responding. It enforces whatever you said as the "last word" on the subject. It also enables a echo chamber where you'll rarely hear people complain about an issue being locked because they can't (because the issue is locked).

Your first sentence is certainly true, and I see what you mean with the second. But I think these statements miss an important point: the issue raised was resolved, and off-topic discussion already begun. From what you've stated, I know you would handle what happened differently (not locking the issue and preferring to omit that last sentence), but I've already voiced why I think those actions were appropriate. It's also worth stating that no one is/was prevented from creating new issues, eg. to complain about an issue being locked.

@sigmavirus24 early on made it explicitly clear that he does not want an echo chamber, even when it might reinforce his own views. Others feel the same way, including myself. I see this as healthy community moderation, and from that I expect the risk of developing echo chambers to be very low. I should state that I don't want to be overbearing. I only share what I do because I see points which I believe should be addressed. There may be some additional context to these discussions, as @asmeurer alluded to "bad behavior" early on, but I'm only able to share my thoughts relevant to this discussion. It might be best if I refrain from adding any further to the thread.

The discussion here is starting to circle. I took a step back because I realized that I responded defensively here when I really should have taken a walk and come back when I was feeling less defensive.

I agree that stating it wasn't our job to answer questions in the issue was the wrong thing to say. By way of explanation (not excuse) the sentiment I was trying to get across was "This is not an appropriate discussion for an issue". I'll try to file that phrase away for future use.

On the other topics:

Perhaps it's worth discussing when PyFlakes locks issues. I do it as a reflex of "This person is ignoring the norms of the community and there's nothing of value in this discussion." regardless of size of project
As an GitHub org owner, I've also used the features of limiting people's ability to interact with projects when they're acting inappropriately but perhaps @asmeurer really wants anyone to always be able to harass and drain maintainer's time and attention. Also worth discussing whether PyFlakes wants to ever have that apply to them.
That said, I would also challenge those who see locking issues as violent or problematic to look outside the Python community for how that tool is used. I gave Requests as an example of where it should be used, but there are many other projects in other languages communities where its done by automation. The feature was born out of the harassment brought upon projects by HN and Reddit, but that doesn't mean that's the only acceptable use

It seems that the OP doesn't care about this issue/discussion. Can we close this one?

agreed, I believe this discussion has long run its course

PyCQA / pyflakes

Improve community experience #557