Re: GitHub Discussions FTW!

Hi Tad! We tried Github discussions at the SPARQL 1.2 group but the
consensus was that we don't like them.
See https://github.com/w3c/sparql-12/issues/136 and
https://github.com/w3c/sparql-12/discussions/137

   - No multilevel threading
   - No backlinks when you cite a discussion in an issue

Still, it has at least 1 level of threading, so that's better for complex
issues that attract many comments.

Hi Dan! Sorry if I was out of line.

I'm willing to put the extra effort of making PRs for issues that are
important to me, just need to learn how. Please point me to a recent PR so
I can see which files to modify, where to put examples, and how to use the
"pending" space.

>  tag stale issues automatically so that the can be bumped back up to get
more of everyone's limited attention

So you see the bot actions as beneficial to the issues? I have some
objections:

   - I think the wide community assumes there's a core project team that
   will decide on the majority of issues. People participate only in issues
   that somehow interest them. There is nothing similar to "Wikidata Projects"
   that are mini-communities on specific topics, and you can ping a Wikidata
   Project when you need (eg when you propose a related property). So I don't
   believe marking an issue as "stale" will increase activity on that issue.
   - There are spurious/arbitrary *bot closures *like these:
   https://github.com/schemaorg/schemaorg/issues/1906,
   https://github.com/schemaorg/schemaorg/issues/2477. All such issues must
   be reopened to try to restore the trust of active community members.

> document the specific structured data "graph shapes" that different
consuming applications are using to validate schema.org data - using
SHACL/ShEx standards

   - The poster of an issue should be able to reopen it, if it's not
   resolved satisfactory.
   - "Active" community members should be able to reopen any issue if they
   have good reasons for that. Eg see
   https://github.com/schemaorg/schemaorg/issues/2291

> document the specific structured data "graph shapes" that different
consuming applications ..  - using SHACL/ShEx standards

Wikidata has both powerful custom constraints, and is quite advanced in
using SHEX constraints.
I agree with you, that would be quite important. I'm willing to help but
have no idea how to organize such an effort.

>move to separate out suggestions, questions, and brainstorming from
proposals that come with a serious commitment to implement in a *consuming*
application

I agree that such classification can streamline the process.
I also agree that priority should be given to new features that have a
commitment for producing or consuming such data (and your movement on
dissolutionLocation, with all of 79 documented instances, is more a
courtesy than a necessity).

But I think that highest priority should be given to BUG reports.
The majority of issues I posted are bug reports.
When they stay stale for 5-6 years, the respective bad patterns are adopted
by producers, and solidified into permanence.
The bad data practices reported by these bugs have a decreasing chance of
being fixed, as time passes.
Cheers!

PS: I doubt I have mail sending rights in this mlist. If not, I'll post a
comment in https://github.com/schemaorg/schemaorg/issues/2573