We have too many open issues (1000)

[danbri]

I am going to freeze the issue creation process for a re-think.

Edit:

• We now have a dedicated repository for suggestions-questions-brainstorming (see "welcome message" issue there). This is inspired by the approach taken in other high profile projects who receive a lot of feedback issues. Issues from our substantive backlog here are being moved across to the suggestions-questions-brainstormin repo (thanks @RichardWallis).
• We are running a "stale issue / pull request" tagging action, to help track neglected issues, and nudge their participants.
• Other things in progress...

[danbri]

Ok it seems we can't control issue creation besides turning it off entirely, since this is a publicly visible repository. I am looking into setting up issue templates and setting the expectation that "brainstormy" issues will be noted and closed.

[smrgeoinfo]

Seems to me that Schema.org has gotten too big for any one committee to manage and address issues. Is it possible to modularize and perhaps delegate management to different workgroups? Seems like the Search providers role here is to be clear about what they will index and use in search results

[danbri]

@smrgeoinfo actually that route didn't work well for us; we tried this with the notion of named extensions (bib, auto, etc.) but we found time and time over that all topics are rather inter-woven. Someone will want an extension for travel, or for tourism, or for hotels, or for real estate, ... and they're all doing very similar work. Same with libraries / archives / museums / galleries. Or IoT vs devices vs healthcare vs agriculture. Everything overlaps.

What we can and should do is separate "suggestion box" issues from areas where there is some commitment to do work.

NodeJS have a "help" repo where issues get transferred; we could do similar.

https://github.com/nodejs/help/issues

There are also projects like Tensorflow with processes we could learn from, https://github.com/tensorflow/tensorflow/blob/master/CONTRIBUTING.md

The project readme, https://github.com/schemaorg/schemaorg/blob/master/README.md tries to set expectations, but it is fairly hidden away.

We try to prioritize simple fixes and improvements to our existing schemas, examples and documentation over the addition of new vocabulary, and we are most likely to add new schemas when there is evidence that some (preferably large-scale) consuming application will make use of the data. Consuming applications need not be search engines; software tools e.g. opensource, markup-enriched approaches to Web analytics, browser add-ons or cloud tools are all rich areas for exploration and collaboration. The important thing is that there should be some reasonable expectation of data consumers making good use of the changes. It is not sufficient to justify additions on the basis that search engines generally try to use Schema.org-based structured data. Smaller changes, and backwards-compatible changes, are easier to incorporate.

[smrgeoinfo]

It's certainly no surprise that there were incompatible results from a wide open invitation to invent extensions to schema.org with the 'folksonomic' approach schema.org has been using. Tower of Babel. What is the purpose of Schema.org. "create, maintain, and promote schemas for structured data on the Internet, on web pages, in email messages, and beyond" is pretty wide open. What is data? Without some high level integration framework (e.g. what ENVO does, and some serious knowledge engineering to review contributions for logical coherence, it's just a tag cloud with some relationships between tags. That has obviously been good enough for lots of applications in basic data discovery where fuzzy semantics are OK, and commercial linking where the semantics are pretty clear cut ("what time is the movie show"...).

I see parallels with SWEET in the Earth Science community. One possible solution that I think is emerging there is to provide the fuzzy terms corresponding to natural language usage, and recognize that domain/community specific mapping from those terms to more logically rigorous/computable knowledge representations are needed for applications that need or can enhance value with inferencing and more explicit/coherent semantics..

Off the soapbox now, I agree that distinguishing 'bug fix' from 'enhancement' issues would be useful. A clearer definition of the purpose and scope of schema.org would be a good thing.

[RichardWallis]

Perhaps the creation of issues should be reserved more for specific actions - bug reports/fixes, enhancement proposal, release control, etc.

Use of the public-schemaorg mailing list should be encouraged for more general questions, discussions, and requests for advice and assistance.

[danbri]

I have created https://github.com/schemaorg/suggestions-questions-brainstorming and will transfer issues there, leaving this repo for things that are expected to get addressed.

The mailing list is also not a great forum for support, but let's deal with that separately.

[smrgeoinfo]

@danbri -- is the idea that the community will submit issues to suggestions-questions-brainstorming, and the vocabulary managers/maintainers will transfer items to this list as targets for upcoming releases?

[jaygray0919]

Google's AMP project (https://github.com/ampproject/amphtml/issues) has several nice features. One is a classification system, with several options to differentiate issues. The second is a bot that periodically says: this has been open for a while; should we close this issue? The bot forces a decision which closes many open issues.

However we disagree with the discussion about segmenting the schema project to working groups, using SWEET as an example. There might be more arbitration panels, circuit courts, appeals courts, etc. - but there has to be a Supreme Court. IOHO, nothing should go into production unless it's been arbitrated before the Supreme Court.

[smrgeoinfo]

Guess I was thinking the 'supreme court' would be the crew that has merge permissions here on schema.org, what I called the 'vocabulary managers/maintainers' above. It would be a tiered review system-- domain-specific workgroups vetting proposals and feeding recommendations to the 'supreme court/maintainer' group.

[jaygray0919]

@smrgeoinfo works for us. We may have over reacted to the SWEET reference as that effort may have under-achieved due to unbridled democracy and the absence of a Supreme Court.

[jvandriel]

Is there a method for sending a message to creators of open issues in bulk? (to ask them whether their issues are still valid, and if not, to close them)

Reason I ask is because over the week I've been going through issues I created myself, only to find out many had become outdated (so I closed them). Seems to me at least the amount of open issues could be substantially reduced if folks would maintain them.

[summercms]

@danbri

There is a simple reason why this repo has so many issues and a very simple fix.

Below is what we use to give you some ideas:

Add some issue template files to this repo!

For question issues send users to Stack Overflow and other places, that way you will not have everything all in one place!

[danbri]

OK, we are moving some issues across into the suggestions-questions-brainstorming repo. Thanks @RichardWallis for taking a lead on this. schemaorg/suggestions-questions-brainstorming#7 is the issue we link over there to contextualize issue-raisers. I think @ayumi-cloud's suggestion to use issue templates is also worth investigating. In addition I've installed (but not really customized yet) a Github Action for tagging stale issues.

[danbri]

Ok, so good news and bad news.

The good news is that we now have a more manageable 558 issues in the main repository. This is important progress towards getting us to a state where we know what we're focussing on, without shutting down useful discussions of possible future work.

The bad news is that the rules for which discussion goes where are not yet clear, and this has caused some frustration. For example @tfrancart asks some very reasonable questions on our public discussion list; I've posted some longer answers there. In brief, one conclusion is that we should avoid moving issues across to suggestions-questions-brainstorming when they are focussed primarily on modest improvements to designs that are already accepted into Schema.org's "Pending" area. I will take this discussion and some earlier text from our readme and propose updates to the how we work document for our steering group to review, which should help set expectations more clearly in future.

/cc @tmarshbing @rvguha @tilid @scor @nicolastorzec

[danbri]

Still to do: @ayumi-cloud made a good suggestion earlier that I don't want to miss: we can use Github's "issue templates" mechanism to help with issue triage.

Here's a candidate list towards having templates, edited down from a chat with @RichardWallis who has read a lot of the 1000s of issues we have here:

• site operation eg. conneg not working or other hosting issues / software bugs
• Vocab usage questions - "how do I express ____?" (we might keep usability issues here, and move new expressivity to the other repo)
• Vocab amendments eg. adjust prop range/tweak description
• Vocab proposals eg. new types/propperties
• Examples: errors, bugs, new examples or json-ld/rdfa/microdata versions of existing examples

See https://docs.github.com/en/github/building-a-strong-community/about-issue-and-pull-request-templates for the Github functionality

[HughP]

Template Suggestions are great, and they can help make sure an issue is actionable. However, as I read the candidate list, it seems to me that some of these are better handled as labels. Labels are good if there is a workflow for addressing them. Clarity in expression and making sure an issue is actionable is still necessary.

…

On Tue, Sep 8, 2020 at 2:30 PM Dan Brickley ***@***.***> wrote: Still to do: @ayumi-cloud <https://github.com/ayumi-cloud> made a good suggestion earlier that I don't want to miss: we can use Github's "issue templates" mechanism to help with issue triage. Here's a candidate list towards having templates, edited down from a chat with @RichardWallis <https://github.com/RichardWallis> who has read a lot of the 1000s of issues we have here: - site operation eg. conneg not working or other hosting issues / software bugs - Vocab usage questions - "how do I express ____?" (we might keep usability issues here, and move new expressivity to the other repo) - Vocab amendments eg. adjust prop range/tweak description - Vocab proposals eg. new types/propperties - Examples: errors, bugs, new examples or json-ld/rdfa/microdata versions of existing examples See https://docs.github.com/en/github/building-a-strong-community/about-issue-and-pull-request-templates for the Github functionality — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2573 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAJ2JXOY5UVAYZ7HYTWSG3SEYPXZANCNFSM4NAVWAVQ> .

[VladimirAlexiev]

"We have too many open issues": is that the reason why you closed automatically unknown quantities of issues recently, after some of them being stuck for 4 years?

And some were moved, I think over to https://github.com/schemaorg/suggestions-questions-brainstorming/issues, where they will probably be stuck for a long time.

There is now a google form to collect suggestions: Leave public feedback on this term 💬. It has 1700 suggestions, of which 40% are bugs (i.e. 425 more).

If you look at
https://docs.google.com/forms/d/e/1FAIpQLSfdGaYIlyG0mylDEEDH8CJEbuMvsylxnpDdJlqjQX3KPl7ImA/viewanalytics, you'll see that the form itself is broken (free-entry classifications?!)

@danbri Sorry to be harsh, but I must say this means that schema.org is failing the community. Forget about new additions, there are some glaring bugs that need fixing. Can't Google allocate some more people to work on Schema?

[github-actions]

This issue is being tagged as Stale due to inactivity.

[VladimirAlexiev]

Ridiculous! https://twitter.com/valexiev1/status/1362773297050583043

[VladimirAlexiev]

https://lists.w3.org/Archives/Public/public-schemaorg/2021Feb/0019.html is a discussion on the topic