doomemacs / ci Goto Github PK

Describe your request

Doom is automatically closing and locking. This should be avoided [1].

See also Drew DeVault's post. The post does not do a good job of expressing the opposing arguments and tradeoffs, but it does contain novel and useful insight.

Note that this issue is not proposing to stop using the "stale" label as it does have value (though very little: it saves one from writing a simple "issueLastUpdatedAt" query fragment)

Briefly explain its use-case

Arguments

Automatic closing

Argument for: stale entities (i.e., issues or PRs) continue to exist even as their time-sensitive context (e.g., master's HEAD) changes. This can cause them to become invalid while potentially still using up maintenance time.
Counterargument: instead, do the following:

• leave the entity open
• at the time of revisiting, a maintainer can if desired (e.g., if reviewing the entity in its stale state is time-consuming and the maintainer wants to save their time), post a comment like "This PR/issue is stale. Interested parties: please review it and post a clear, updated description." And label the issue with, e.g., needs-updating that can be used in issue queries.

For: many stale PRs can discourage contributors, and many stale issues can discourage issue browsers
Counter: it is not clear that automatic closure feels or is perceived better than absence. Instead, better solutions are setting expectations for maintenance volume via, e.g., pinned issues or CONTRIBUTING.md or README.md or issue templates. Or, of course, increasing maintenance volume, though that is obviously much more challenging.
Tangent: the usage of a "stale" label calls attention to that and therefore likely augments the perceived staleness of issues.

Against: automatic closing introduces extra annoyance and busy work, e.g., having to comment to prevent closure, reopen issues or create new ones with a link to the old one(s).

Against: it breaks from the semantics of "closed" [2]. "Closed" means "will not be developed" (note that this includes the "because it has already been developed" case). Following semantics makes things easier to understand, organize and search.

Against: it, when a contributor isn't aware or willing to search in issues closed due to staleness, limits the options of what they can work on. New contributors, often more focused on learning, skew toward non-urgent issues and issues nobody else intends to work on. Therefore, they tend to especially appreciate a higher availability of stale issues.

Automatic locking

For: it lowers notification volume for contributors
Counter: one can achieve the same through notification configuration. Even if GitHub's notification panel does not allow sufficient granularity, email filters do (this requires using email as the notification interface, but that is far superior given some light configuration or tooling).

Against: it introduces obstacles to further collaborating on a topic.

---

Note: I have never been a maintainer of a large open-source project, so I fully expect that there are "arguments for" that I have not addressed here.

[1] This is an opinion. Further, beware of the many implicit (so that the text is less verbose and dull) opinions here.
[2] If it did not break semantics, it would be asserting "nobody has commented recently => nobody wants this => this will not be developed." This would be an error: e.g.
- people might forget to subscribe to the issue or not see the GitHub notification (apparently, many struggle with this due to poor notification configuration).
- the idea expressed in the issue may be desirable and unusual (the latter characteristic could cause low comment frequency as most may not have realized that it would benefit them) but may have been deprioritized for some reason (e.g., taking non-trivial time/effort to implement)

What would you like to know?

I just saw the https://discourse.doomemacs.org/t/development-roadmap/42

Is there anything which need to be improved in this action?

What would you like to know?

Do you really need to add runner.os in the cache key if you are simply putting clones of git repositories in the cache values ? If the straight recipes don't change for each OS, I don't see a reason to make 3 different caches of straight/repos for the same profile on 3 os.

Then again, I don't know what information the hash of the profile contains, so feel free to close that