{"id":40,"date":"2016-08-24T15:48:20","date_gmt":"2016-08-24T15:48:20","guid":{"rendered":"https:\/\/www.w3.org\/community\/schemaorg\/?page_id=40"},"modified":"2021-07-14T07:41:38","modified_gmt":"2021-07-14T07:41:38","slug":"issue-management-on-github","status":"publish","type":"page","link":"https:\/\/www.w3.org\/community\/schemaorg\/how-we-work\/issue-management-on-github\/","title":{"rendered":"Issue management on Github"},"content":{"rendered":"<p>Schema.org uses GitHub for collaboration. We have both a&nbsp;GitHub <a href=\"http:\/\/github.com\/schemaorg\/schemaorg\/\" target=\"_blank\" rel=\"nofollow\">repository<\/a> for the project, as well as an issue tracker. This page gives some overview of how we are using our&nbsp;GitHub <a href=\"http:\/\/github.com\/schemaorg\/schemaorg\/issues\" target=\"_blank\" rel=\"nofollow\">issue tracker<\/a>.<\/p>\n<p>Anyone (once they have created an account) can open a schema.org GitHub issue, or comment on an existing issue. Issues can be tagged with one or more <a href=\"https:\/\/github.com\/schemaorg\/schemaorg\/labels\" target=\"_blank\" rel=\"nofollow\">labels<\/a>, and&nbsp;will be either marked &#8220;open&#8221; or &#8220;closed&#8221;.<\/p>\n<p><strong>Open vs&nbsp;Closed status<\/strong><\/p>\n<p>Due to the broad scope of schema.org &#8211; descriptions of&nbsp;things that are commonly mentioned in Web pages &#8211; we receive a great many valuable suggestions for potential improvements. Over time these have accumulated&nbsp;and at the time of writing&nbsp;there are over 400 open issues (and over 450 that we have closed). We are moving towards a process in which it will be more common for issues to be&nbsp;marked as <em>closed<\/em>. This page serves to document more clearly what &#8216;closed&#8217; means in the context of the schema.org project.<\/p>\n<p>Issues are marked &#8220;open&#8221; in several situations:<\/p>\n<ul>\n<li>They have just been filed or have not been reviewed.<\/li>\n<li>They propose vocabulary in an area where work is likely or ongoing, or which looks like a simple easy addition.<\/li>\n<li>They propose tooling \/ infrastructure&nbsp;improvements to the site that is likely, ongoing or easy.<\/li>\n<li>The correspond to a vocabulary-proposing issue&nbsp;for which we have published an exploratory implementation at pending.schema.org.<\/li>\n<li>They raise a technical or tooling issue.<\/li>\n<\/ul>\n<p>Issues may be marked as &#8220;closed&#8221; in situations where:<\/p>\n<ul>\n<li>The&nbsp;issue, problem or question they raise has been&nbsp;addressed.<\/li>\n<li>The issue&nbsp;isn&#8217;t one we can usefully help with.<\/li>\n<li>The&nbsp;raised issue outlined is noted (via <a href=\"http:\/\/github.com\/schemaorg\/schemaorg\/issues\/2\" target=\"_blank\" rel=\"nofollow\">Issue #2<\/a>) as a&nbsp;sensible or good vocabulary idea&nbsp;but which will need attention&nbsp;later as part of a larger cluster of work.<\/li>\n<li>The&nbsp;raised issue outlined is noted (via <a href=\"http:\/\/github.com\/schemaorg\/schemaorg\/issues\/3\" target=\"_blank\" rel=\"nofollow\">Issue #3<\/a>) as a&nbsp;sensible or good tooling \/ site infrastructure&nbsp;idea&nbsp;but which will need attention&nbsp;later as part of a larger cluster of work.<\/li>\n<\/ul>\n<p>This&nbsp;structure means that many good ideas will be marked as &#8220;closed&#8221;. This status&nbsp;should not discourage discussion, it is just our way of coping with a potentially endless&nbsp;stream of schema suggestions. Schema.org&#8217;s scope is as open-ended as Web search; this means we have to prioritize, balancing &#8220;quick fixes&#8221; with high impact but complex design discussions. Our&nbsp;mechanism for handling an ever growing collection of vocabulary proposals is to make sure that they are labelled, noted from our top level tracking issue (<a href=\"http:\/\/github.com\/schemaorg\/schemaorg\/issues\/2\" target=\"_blank\" rel=\"nofollow\">#2<\/a>), and that it is clear that &#8220;closed&#8221; does not mean &#8220;will never be addressed&#8221;.<\/p>\n<p>The overview issue&nbsp;(plus GitHub&#8217;s search facilities)&nbsp;provide discovery mechanisms for closed issues.<\/p>\n<p><strong>Issue labels and status changes<\/strong><\/p>\n<p>Issues are most commonly&nbsp;closed&nbsp;by the community group chair \/ webmaster, but also sometimes by those&nbsp;in the project&nbsp;steering group and wider community who have been&nbsp;leading discussions in a particular area.<\/p>\n<p><strong>Prioritization<\/strong><\/p>\n<p>We have historically attempted more explicit issue prioritization. It has proved difficult to predict when the right combination of people&#8217;s time\/attention and consensus will combine to produce results.&nbsp;For earlier releases, we allocated issues to release-oriented Milestones, but this was&nbsp;not very successful. Currently the best view of priorities comes via a per-release issue in which&nbsp;the community discuss which areas are nearing consensus. These are always linked from&nbsp;the entry point issue, conveniently numbered <a href=\"https:\/\/github.com\/schemaorg\/schemaorg\/issues\/1\" target=\"_blank\" rel=\"nofollow\">Issue #1<\/a>.<\/p>\n<p>At the present time (August 2016), a meta-priority is to get our open issue list down to a manageable level. Roughly this is to have &lt; 100 open vocabulary issues, and &lt; 50 open infrastructure\/tooling issues.<\/p>\n<a href=\"https:\/\/github.com\/schemaorg\/schemaorg\/issues\/\" target=\"_blank\" rel=\"nofollow\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/pbs.twimg.com\/media\/CpgcqQOWIAAraBP.jpg:large\" alt=\"A table covered with printed open issues in paper card form.\" width=\"406\" height=\"197\"><\/a> Schema.org Issue cards\n","protected":false},"excerpt":{"rendered":"<p>Schema.org uses GitHub for collaboration. We have both a&nbsp;GitHub repository for the project, as well as an issue tracker. This page gives some overview of how we are using our&nbsp;GitHub issue tracker. Anyone (once they have created an account) can &hellip; <a href=\"https:\/\/www.w3.org\/community\/schemaorg\/how-we-work\/issue-management-on-github\/\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":44,"featured_media":0,"parent":18,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"_s2mail":"yes","footnotes":""},"class_list":["post-40","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.w3.org\/community\/schemaorg\/wp-json\/wp\/v2\/pages\/40","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.w3.org\/community\/schemaorg\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.w3.org\/community\/schemaorg\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.w3.org\/community\/schemaorg\/wp-json\/wp\/v2\/users\/44"}],"replies":[{"embeddable":true,"href":"https:\/\/www.w3.org\/community\/schemaorg\/wp-json\/wp\/v2\/comments?post=40"}],"version-history":[{"count":7,"href":"https:\/\/www.w3.org\/community\/schemaorg\/wp-json\/wp\/v2\/pages\/40\/revisions"}],"predecessor-version":[{"id":56,"href":"https:\/\/www.w3.org\/community\/schemaorg\/wp-json\/wp\/v2\/pages\/40\/revisions\/56"}],"up":[{"embeddable":true,"href":"https:\/\/www.w3.org\/community\/schemaorg\/wp-json\/wp\/v2\/pages\/18"}],"wp:attachment":[{"href":"https:\/\/www.w3.org\/community\/schemaorg\/wp-json\/wp\/v2\/media?parent=40"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}