Tldr: List of commands and how to best use them

Created on 4 Jun 2019  路  10Comments  路  Source: tldr-pages/tldr

Before I knew the existence of this I more or less wrote out this page:
Linux Tools

I am not sure how much of what is on my page is already in TLDR, but yeah happy to contribute anything that is missing...

Most helpful comment

Note that I'm not suggesting leaving the issue open indefinitely if the reporter doesn't respond,

That sounds like extra work of going through old issues and checking if the reported has responded or not.

It is a tradeoff either ways :smile: In any case, I agree on the overall sentiment.

All 10 comments

Nice, @StewAlexanderACC! You're welcome to contribute pages for commands on that list that don't already exist :D

Thank you for the link @StewAlexanderACC. I'm closing this though, since this is basically just you expressing your interest in the project and doesn't look like there's much to add to the discussion (I saw you open other more specific issues here). If there's something more you would like to discuss, just let me know and I'll reopen this.

With that said, thank you for the interest and the helpful link :blush:! And as @sbrl said, you're of course most welcome to contribute by adding pages and/or examples yourself. Just give CONTRIBUTING.md a read if you're interested.

Hey @mebeim, just a small note: when closing issues, I find it best to first announce that intention and await the reporter's reaction confirming their agreement, otherwise if can feel a bit aggressive on the other side, even if it isn't the maintainer's intent.

Remember that people without write access to the repo cannot reopen issues closed by a maintainer, so closing is really a strong action that unilaterally shuts down a discussion, and as such it should be wielded with care.

Sorry about that, I saw no harm in closing this issue with a proper comment, it's a mean of feedback and of course I explained why it was closed and pointed out my availability to reopen it if ever needed. I just prefer avoiding having open and stale issues if there really isn't anything to discuss. That's why those can be reopened anyway, isn't it? This stayed open for 3 days and was just a message for an interesting link.

I don't see much regarding the matter in maintainers-guide.md. Maybe we should add a note about issue handling?

Great point, @waldyrious. Ping @Aracki IIRC.

IMO, @mebeim handled it fine. It did not seem aggressive to me. And if the OP felt otherwise, they can always comment on the issue asking it to be reopened. And tbh, this isn't even an issue, the OP just wanted to contribute and they just wanted to announce it. That was received with a warm welcome and pointed to the right direction.

That being said, if this was such an issue where something was needed from OP's side, then sure, it makes sense to wait for more information before closing it. But I don't see this being one. Another example would be client specific issues, we just point them to the right client asking them to open an issue there, and close the issue. No harm in that.

I hate every single thing written down to be followed. That just feels like a lot of rules and takes the fun out of contributing to open source. As long as we are nice to each other and treat everyone with respect, that's all that matters to me.

To be clear, I didn't mean to imply it was aggressive, just that it could be perceived as that. I've been on the opposite side of such interactions many times, and it just feels a little rude to be told "this conversation is over" unilaterally, no matter how politely it is phrased.

Again, the main issue is that the maintainer can reopen the issue, but the reporter can't. Even if the maintainer offers to reopen if the reporter requests it, the fact that they have to ask for someone else to take an action instead of performing it themselves is an objective reduction of agency.

Since we can minimize that with a simple extra step on our side, I think it's a reasonable pattern to adopt. Note that I'm not suggesting leaving the issue open indefinitely if the reporter doesn't respond, or unconditionally keeping it open if they disagree with the maintainers that it should be closed. But at least they'd have a say in the closure of the discussion.

ps: this is not at all a big deal! It's just something I'd like us to adopt not as a strict or written-down rule, but as a part of our community's culture to be welcoming and friendly.

I hate every single thing written down to be followed. That just feels like a lot of rules and takes the fun out of contributing to open source. As long as we are nice to each other and treat everyone with respect, that's all that matters to me.

It's just something I'd like us to adopt not as a strict or written-down rule, but as a part of our community's culture to be welcoming and friendly.

Totally agree guys.

Since we can minimize that with a simple extra step on our side, I think it's a reasonable pattern to adopt.

Well, makes sense, will do!

Note that I'm not suggesting leaving the issue open indefinitely if the reporter doesn't respond,

That sounds like extra work of going through old issues and checking if the reported has responded or not.

It is a tradeoff either ways :smile: In any case, I agree on the overall sentiment.

In any case, I agree on the overall sentiment.

That's good enough to me :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

taki picture taki  路  3Comments

waldyrious picture waldyrious  路  4Comments

TobiasRoland picture TobiasRoland  路  3Comments

Wesalius picture Wesalius  路  3Comments

hrai picture hrai  路  3Comments