Import content from manpages with EXAMPLES sections

[waldyrious]

In parallel with #1070 (and as alluded to here), it seems like a quick way to add a bunch of additional content could be to locate manpages that already contain an EXAMPLES section, and use those as seeds for new tldr pages.

We could even have a bot automatically create those PRs (maybe even with some of the syntax conversion done via simple rules), which we would then tweak to match our standards.

[zlatanvasovic]

TBH, it seems like a waste of time to me. The time we'd spend to fix the incompatible pages could be used to write new pages. And the most of man pages have already been swallowed by this project's ever-growing entry list.

I'm for closing this, and you @waldyrious?

[sbrl]

I'm not so sure. If we're going by coverage, we've got a whole ton of basic commands left to do (see #2214 for example, or my tldr-missing-pages command in my apt repository (source).

[agnivade]

While I agree that this would be good to have, realistically speaking this is doubtful to happen. #1070 has some importance, but this is just good to have. If there isn't much interest, I think we can close it.

Probably we can document these as a wishlist somewhere. Not sure.

[ivanhercaz]

Probably we can document these as a wishlist somewhere. Not sure.

We could make an issue with the title Wishlist and make a list of wishes (improvements/features to apply
) and link the issues related with each wish.

One thing that I usually like in repositories are labels for priority (eg. priority:high and priority:low). This helps me to know in which issues I should focus my efforts. It is something visually that in my opinion make easier the organization.

[sbrl]

We've already got a few projects outline on the repository wiki. Perhaps this would be a good fit there as a programming project (maybe even a Google Code-In / Summer of Code) project submission?)

Edit: Link

[waldyrious]

I don't think the reasons above justify closing the issue. In particular:

TBH, it seems like a waste of time to me. The time we'd spend to fix the incompatible pages could be used to write new pages.

I don't see this task as competing with the others for the same (human) resources. The motivation for doing this most likely comes from a different place than the motivation to create new pages. In fact, I think it would be a waste not to make use of use existing EXAMPLES sections (for content we don't already have, mind you), since the curation work was already done, and most of what's missing is the formatting.

And the most of man pages have already been swallowed by this project's ever-growing entry list.

Agreed, but (1) the examples may be different, and their selection could be more balanced than ours, or there could be examples that we are lacking, and (2) whatever content we already have and don't need to import — great! Less work to do :)

While I agree that this would be good to have, realistically speaking this is doubtful to happen. If there isn't much interest, I think we can close it.

Are we seeking an "inbox zero" strategy for issues? I've got this feeling recently, with a lot of proposals to close old issues. I would prefer to keep issues open if we have no opposition to them being done (e.g. if we'd welcome a PR that implemented them). There's no shortage of space or anything, and old issues that gather little interest naturally end up at the end of the issues list anyway (since GitHub automatically sorts it by last activity date), so there isn't a "pollution" issue either. Do you guys feel otherwise?

[waldyrious]

By the way, my point above about tasks competing with each other also relates to @ivanhercaz's comment:

One thing that I usually like in repositories are labels for priority (eg. priority:high and priority:low). This helps me to know in which issues I should focus my efforts. It is something visually that in my opinion make easier the organization.

Please keep in mind that this is a decentralized, collaborative project that aggregates people with different motivations, and different notions of what is important or not. There isn't supposed to be a centralized priority list that everyone should follow (neither the maintainers, nor any user in particular).

It is also a volunteer project, which means that it's very important to preserve (encourage, even!) everyone's autonomy to decide for their own what tasks appeal to them and work on them based on their personal desire and interest, rather than a sense of "this is work that needs to be done".

Treating the issues list as a task list that needs to be emptied (or as a centralized source of priority information) erodes the decentralized and self-directed aspects of the project, and is a step towards erecting barriers between insiders and newcomers, and towards eventually producing burn-out when people start feeling they aren't taking pleasure from being part of this endeavor.

We must keep these principles in mind if we want the project to be sustainable in the long term (and embed them in our culture, so that they remain in place long after we're all moved to other things).

[agnivade]

I have no issues with keeping this open. It's just that I think this is pretty low on the priority list and nobody has shown any interest on it for 3 years. So issues like these just lie here gathering dust.

I am not saying to just close these and lose track of them. But for low-priority issues like these, I like @sbrl's idea of putting them on a wish-list on a wiki page or something.

Just a thought.

[zlatanvasovic]

That's a good idea, @agnivade. By doing that, #3752 would become (mostly) resolved.