Proposal: add issue templates to this repo

[melvincarvalho]

In github it is possible to create issue templates in order to guide a user in how to express an issue

There was concern expressed about confusion caused when raising spec related issues

Creating issue templates could have the effect of killing two birds with one stone

• Improving the quality and nature of issues raised here (which in isolation would be a good thing)
• Ability to guide users more effectively going forward

I propose that we begin with the standard two types of issue templates

• bug reports
• feature requests

The text then becomes part of the repository. And it would be possible to iterate on that text.

[csarven]

Feature requests is out of scope of 0.7. They belong in the solid/specification repository.

New issues can only be about erratas to the 0.7 spec.

[melvincarvalho]

@csarven thanks for the input

The idea of feature requests would be to guide the user in where to post

Another way would be only to have a bug report item with an explanatory message:

One looks like this:

The other looks like this:

You can imagine that boiler plate text to be something useful to guide the user and lower confusion

Supportive of guiding users NOT to raise feature requests, using either path

[dmitrizagidulin]

-1 to this. This repository is archived. There is no need for issue templates for it.

[kidehen]

In github it is possible to create issue templates in order to guide a user in how to express an issue

There was concern expressed about confusion caused when raising spec related issues

Creating issue templates could have the effect of killing two birds with one stone

• Improving the quality and nature of issues raised here (which in isolation would be a good thing)
• Ability to guide users more effectively going forward

I propose that we begin with the standard two types of issue templates

• bug reports
• feature requests

The text then becomes part of the repository. And it would be possible to iterate on that text.

How about dropping the "Feature Request" option so that whoever encounters the form ends up performing either of the following actions:

1. Logs a fix or correction to the draft repo
2. Seeks an alternative repo (i.e., specifications overseen by @csarven) for new features related matters.

The suggestion above should solve the problem that's underlying this thread. IMHO.

[dmitrizagidulin]

@kidehen

The suggestion above should solve the problem that's underlying this thread. IMHO.

The problem underlying this thread is - this repository is no longer active. It does not need an issue template, since no new issues will be created.

[akuckartz]

@melvincarvalho If the other stakeholders will agree with this very likely depends on the text of the templates.

[kidehen]

@kidehen

The suggestion above should solve the problem that's underlying this thread. IMHO.

The problem underlying this thread is - this repository is no longer active. It does not need an issue template, since no new issues will be created.

That worldview is the basis for the objection raised by @melvincarvalho.

We have conflicting world-views here and the goal is to solve this issue harmoniously for the betterment of the broader community.

Again, I am calling to flexibility here with a fundamental understanding that individuality and community can be strange bedfellows, especially with the behavior of an app (like what's provided by Github) in the mix.

[kidehen]

Feature requests is out of scope of 0.7. They belong in the solid/specification repository.

New issues can only be about erratas to the 0.7 spec.

Okay, and I believe that's consistent with the template modifications I suggested earlier to @melvincarvalho .

[dmitrizagidulin]

@kidehen

Again, I am calling to flexibility here with a fundamental understanding that individuality and community can be strange bedfellows, especially with the behavior of an app (like what's provided by Github) in the mix.

The impression that I'm (likely erroneously) getting, is that this discussion is proposing is to fork the Solid project and community.

This by itself is totally fine. Forking is a time-honored tool, and is important to free software in general.

What is not fine, is to create this fork at the expense of causing confusion for Solid developers, which is what not explicitly archiving this solid-spec repo would result in.

[kidehen]

Let's be very clear here. What you and @melvincarvalho are proposing is to fork the Solid project and community.

This by itself is totally fine. Forking is a time-honored tool, and is important to free software in general.

What is not fine, is to create this fork at the expense of causing confusion for Solid developers, which is what not explicitly archiving this solid-spec repo would result in.

I want to be crystal clear with you.

My involvement in this thread is strictly about contributing what I can to calm things down by urging flexibility and mutual understanding across differing views.

Once again, I am simply calling on the "Wisdom of Solomon" to be applied for the greater good.

I hope I have made myself intentions clearer, if prior attempts haven't achieved that fundamental goal.

[dmitrizagidulin]

@kidehen ah, thank you, my apologies. I do appreciate you wanting to calm the discussion. Sorry bout that.

[kidehen]

Feature requests is out of scope of 0.7. They belong in the solid/specification repository.

New issues can only be about erratas to the 0.7 spec.

Yes, and we can achieve that via the tweak suggested in my response :)

Issues associated with 0.7 are fundamentally of type: errata i.e., no "new features" goal is achieved by not including any "new feature" option in the template that @melvincarvalho is putting together.

[akuckartz]

no "new features" goal is achieved by not including any "new feature" option in the template that @melvincarvalho is putting together.

One alternatively could provide a pseudo "new feature" option with a template text like:

"Do not suggest new features in this repository. Do that in the other repository nearby. Please see our README for an explanation."

[kidehen]

no "new features" goal is achieved by not including any "new feature" option in the template that @melvincarvalho is putting together.

One alternatively could provide a pseudo "new feature" option with a template text like:

"Do not suggest new features in this repository. Do that in the other repository nearby. Please see our README for an explanation."

Yes, but leaving out "new features" all together in the template helps to avert confusion that will inevitably arise if "new feature" appears as an option or pseudo-option etc..

[akuckartz]

@kidehen Yes, but if someone is already looking for a way to submit a feature request he or she will perhaps simply submit a "bug" instead.

Anyway, I think the README is what matters even more.