Closed jaimergp closed 2 months ago
Yes, we should revisit the templates and default labels (the hack labels should probably just be all combined into one, no need to have unique ones)
I also recently learned that the sync action we use supports templating, so that should help us significantly with this effort.
Regarding the bug issue template, we included the conda fields assumpting that errors in downstream tools or plugins would still need the info
, config
, and list
for debugging purposes.
But I can see how menuinst
and conda-standalone
don't need these details so we probably want a bug issue form with conda details and a separate bug issue form without conda details.
Hi there, thank you for your contribution!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further activity occurs.
If you would like this issue to remain open please:
NOTE: If this issue was closed prematurely, please leave a comment.
Thanks!
Checklist
What is the idea?
The current set of defauls are a bit too
conda/conda
specific for my taste. For example, inconda/constructor
I see:conda/conda
; e.g. all thosehack::*
ones?conda
installation but nothing aboutconstructor
. The intro paragraphs focus on "Conda" (maybe as a community? but it's unclear and distracting).Why is this needed?
It is confusing for maintainers and users to be required to fill data that is irrelevant for the project.
What should happen?
Ideally we would have a nice set of defaults that can be overridden with some mechanism of customization. Maybe templated templates (meta!), or just changing the language so it's more generic, or maintaining some of the templates per-repo.
Additional Context
This can also be observed in other repositories like
menuinst
orconda-standalone