You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Jan Piotrowski <pi...@gmail.com> on 2018/08/09 21:07:22 UTC
[DISCUSS] [Github Issues] Issue and Pull Request labels
Now that we have Github issues enabled for all our repositories,
another new thing we have to talk about are Github Issue and Pull
Request labels.
If you are not aware of Github labels, here is a nice introduction:
https://help.github.com/articles/about-labels/
This also contains a list of the default labels all our repositories
got when issues were enabled:
> bug, duplicate, good first issue, help wanted, invalid, question, wontfix
https://help.github.com/articles/about-labels/#using-default-labels
Issues also have a color, which - when chosen well and used uniform
across repositories - make it easier to scan the issue list.
As we come from JIRA, it's important to understand the differences.
A JIRA ticket has many different fields: Type, Status, Priority,
Resolution, Affects Version/s, Fix Version/s, Component/s, Labels,
Security Level, Environment, Estimate, Flag, External issue URL,
External issue ID, Epic Link, Sprint, Docs Text
On Github none of those exist. Most of this information has to be
supplied via the description of the issue (and can be requested via
the issue or PR template, see previous email), but it can also make
sense to map some of those via Github labels.
With the first few issues that came in on our repositories, I already
created the following two new labels:
- `support` - Used for support questions that don't report a bug and
don't request a new feature but e.g. want to understand how something
works, need help debugging their individual problem etc. (This will
probably be the majority of the issue we are getting.)
- `platform: android` (ios, browser, windows, osx) - For plugin
repositories it makes sense to categorize e.g. a bug report or feature
request for its platform
Other projects have very structured labels:
https://github.com/fastlane/fastlane/labels
https://github.com/ionic-team/ionic-cli/labels
Or pretty extensive lists of stuff:
https://github.com/Microsoft/TypeScript/labels
https://github.com/Microsoft/vscode/labels
What do we actually need for the beginning?
Any other input?
Does anyone have an idea how we can "manage" our labels across our ~70
repositories? Are there any scripts out there that can automate the
creation/deletion of them via the Github API?
Best,
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [DISCUSS] [Github Issues] Issue and Pull Request labels
Posted by Jan Piotrowski <pi...@gmail.com>.
This is now a Pull Request:
https://github.com/apache/cordova-contribute/pull/4
(It also contains some initial research on how exactly and with what
tools we might be able to roll out these labels to all repositories)
Please keep all further discussion on labels in this Pull Request. Thank you.
2018-08-23 10:05 GMT+02:00 <ra...@gmail.com>:
> I wanted to use GitHub's GraphQL to gather some insights about cordova
> repos. I could not access some organization level information that I could
> see over the web, without requesting organization (apache) wide privileges
> for GraphQL.
>
> So it's not always that easy.
>
> Shazron <sh...@gmail.com> schrieb am Do., 23. Aug. 2018, 07:56:
>
>> I would assume since we (committers) can create a New Label in Github,
>> we would have the permission to do so via API...
>> On Wed, Aug 22, 2018 at 2:28 AM <ra...@gmail.com> wrote:
>> >
>> > Labels that I would like to have:
>> >
>> > - something to show that you are open to suggestions or want to work out
>> > how something is supposed to work. Could be "discussion"
>> > - A "Work in Progress" label
>> >
>> > I would have tried to just write a script that creates the labels via GH
>> > API. But do we have the necessary permissions to do so?
>> >
>> > Jan Piotrowski <pi...@gmail.com> schrieb am Do., 9. Aug. 2018,
>> 23:07:
>> >
>> > > Now that we have Github issues enabled for all our repositories,
>> > > another new thing we have to talk about are Github Issue and Pull
>> > > Request labels.
>> > >
>> > >
>> > > If you are not aware of Github labels, here is a nice introduction:
>> > > https://help.github.com/articles/about-labels/
>> > >
>> > > This also contains a list of the default labels all our repositories
>> > > got when issues were enabled:
>> > >
>> > > > bug, duplicate, good first issue, help wanted, invalid, question,
>> wontfix
>> > >
>> > > https://help.github.com/articles/about-labels/#using-default-labels
>> > >
>> > > Issues also have a color, which - when chosen well and used uniform
>> > > across repositories - make it easier to scan the issue list.
>> > >
>> > >
>> > > As we come from JIRA, it's important to understand the differences.
>> > > A JIRA ticket has many different fields: Type, Status, Priority,
>> > > Resolution, Affects Version/s, Fix Version/s, Component/s, Labels,
>> > > Security Level, Environment, Estimate, Flag, External issue URL,
>> > > External issue ID, Epic Link, Sprint, Docs Text
>> > > On Github none of those exist. Most of this information has to be
>> > > supplied via the description of the issue (and can be requested via
>> > > the issue or PR template, see previous email), but it can also make
>> > > sense to map some of those via Github labels.
>> > >
>> > >
>> > > With the first few issues that came in on our repositories, I already
>> > > created the following two new labels:
>> > >
>> > > - `support` - Used for support questions that don't report a bug and
>> > > don't request a new feature but e.g. want to understand how something
>> > > works, need help debugging their individual problem etc. (This will
>> > > probably be the majority of the issue we are getting.)
>> > > - `platform: android` (ios, browser, windows, osx) - For plugin
>> > > repositories it makes sense to categorize e.g. a bug report or feature
>> > > request for its platform
>> > >
>> > >
>> > > Other projects have very structured labels:
>> > > https://github.com/fastlane/fastlane/labels
>> > > https://github.com/ionic-team/ionic-cli/labels
>> > >
>> > > Or pretty extensive lists of stuff:
>> > > https://github.com/Microsoft/TypeScript/labels
>> > > https://github.com/Microsoft/vscode/labels
>> > >
>> > > What do we actually need for the beginning?
>> > > Any other input?
>> > >
>> > >
>> > > Does anyone have an idea how we can "manage" our labels across our ~70
>> > > repositories? Are there any scripts out there that can automate the
>> > > creation/deletion of them via the Github API?
>> > >
>> > >
>> > > Best,
>> > > Jan
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> > > For additional commands, e-mail: dev-help@cordova.apache.org
>> > >
>> > >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [DISCUSS] [Github Issues] Issue and Pull Request labels
Posted by ra...@gmail.com.
I wanted to use GitHub's GraphQL to gather some insights about cordova
repos. I could not access some organization level information that I could
see over the web, without requesting organization (apache) wide privileges
for GraphQL.
So it's not always that easy.
Shazron <sh...@gmail.com> schrieb am Do., 23. Aug. 2018, 07:56:
> I would assume since we (committers) can create a New Label in Github,
> we would have the permission to do so via API...
> On Wed, Aug 22, 2018 at 2:28 AM <ra...@gmail.com> wrote:
> >
> > Labels that I would like to have:
> >
> > - something to show that you are open to suggestions or want to work out
> > how something is supposed to work. Could be "discussion"
> > - A "Work in Progress" label
> >
> > I would have tried to just write a script that creates the labels via GH
> > API. But do we have the necessary permissions to do so?
> >
> > Jan Piotrowski <pi...@gmail.com> schrieb am Do., 9. Aug. 2018,
> 23:07:
> >
> > > Now that we have Github issues enabled for all our repositories,
> > > another new thing we have to talk about are Github Issue and Pull
> > > Request labels.
> > >
> > >
> > > If you are not aware of Github labels, here is a nice introduction:
> > > https://help.github.com/articles/about-labels/
> > >
> > > This also contains a list of the default labels all our repositories
> > > got when issues were enabled:
> > >
> > > > bug, duplicate, good first issue, help wanted, invalid, question,
> wontfix
> > >
> > > https://help.github.com/articles/about-labels/#using-default-labels
> > >
> > > Issues also have a color, which - when chosen well and used uniform
> > > across repositories - make it easier to scan the issue list.
> > >
> > >
> > > As we come from JIRA, it's important to understand the differences.
> > > A JIRA ticket has many different fields: Type, Status, Priority,
> > > Resolution, Affects Version/s, Fix Version/s, Component/s, Labels,
> > > Security Level, Environment, Estimate, Flag, External issue URL,
> > > External issue ID, Epic Link, Sprint, Docs Text
> > > On Github none of those exist. Most of this information has to be
> > > supplied via the description of the issue (and can be requested via
> > > the issue or PR template, see previous email), but it can also make
> > > sense to map some of those via Github labels.
> > >
> > >
> > > With the first few issues that came in on our repositories, I already
> > > created the following two new labels:
> > >
> > > - `support` - Used for support questions that don't report a bug and
> > > don't request a new feature but e.g. want to understand how something
> > > works, need help debugging their individual problem etc. (This will
> > > probably be the majority of the issue we are getting.)
> > > - `platform: android` (ios, browser, windows, osx) - For plugin
> > > repositories it makes sense to categorize e.g. a bug report or feature
> > > request for its platform
> > >
> > >
> > > Other projects have very structured labels:
> > > https://github.com/fastlane/fastlane/labels
> > > https://github.com/ionic-team/ionic-cli/labels
> > >
> > > Or pretty extensive lists of stuff:
> > > https://github.com/Microsoft/TypeScript/labels
> > > https://github.com/Microsoft/vscode/labels
> > >
> > > What do we actually need for the beginning?
> > > Any other input?
> > >
> > >
> > > Does anyone have an idea how we can "manage" our labels across our ~70
> > > repositories? Are there any scripts out there that can automate the
> > > creation/deletion of them via the Github API?
> > >
> > >
> > > Best,
> > > Jan
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > For additional commands, e-mail: dev-help@cordova.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
Re: [DISCUSS] [Github Issues] Issue and Pull Request labels
Posted by Shazron <sh...@gmail.com>.
I would assume since we (committers) can create a New Label in Github,
we would have the permission to do so via API...
On Wed, Aug 22, 2018 at 2:28 AM <ra...@gmail.com> wrote:
>
> Labels that I would like to have:
>
> - something to show that you are open to suggestions or want to work out
> how something is supposed to work. Could be "discussion"
> - A "Work in Progress" label
>
> I would have tried to just write a script that creates the labels via GH
> API. But do we have the necessary permissions to do so?
>
> Jan Piotrowski <pi...@gmail.com> schrieb am Do., 9. Aug. 2018, 23:07:
>
> > Now that we have Github issues enabled for all our repositories,
> > another new thing we have to talk about are Github Issue and Pull
> > Request labels.
> >
> >
> > If you are not aware of Github labels, here is a nice introduction:
> > https://help.github.com/articles/about-labels/
> >
> > This also contains a list of the default labels all our repositories
> > got when issues were enabled:
> >
> > > bug, duplicate, good first issue, help wanted, invalid, question, wontfix
> >
> > https://help.github.com/articles/about-labels/#using-default-labels
> >
> > Issues also have a color, which - when chosen well and used uniform
> > across repositories - make it easier to scan the issue list.
> >
> >
> > As we come from JIRA, it's important to understand the differences.
> > A JIRA ticket has many different fields: Type, Status, Priority,
> > Resolution, Affects Version/s, Fix Version/s, Component/s, Labels,
> > Security Level, Environment, Estimate, Flag, External issue URL,
> > External issue ID, Epic Link, Sprint, Docs Text
> > On Github none of those exist. Most of this information has to be
> > supplied via the description of the issue (and can be requested via
> > the issue or PR template, see previous email), but it can also make
> > sense to map some of those via Github labels.
> >
> >
> > With the first few issues that came in on our repositories, I already
> > created the following two new labels:
> >
> > - `support` - Used for support questions that don't report a bug and
> > don't request a new feature but e.g. want to understand how something
> > works, need help debugging their individual problem etc. (This will
> > probably be the majority of the issue we are getting.)
> > - `platform: android` (ios, browser, windows, osx) - For plugin
> > repositories it makes sense to categorize e.g. a bug report or feature
> > request for its platform
> >
> >
> > Other projects have very structured labels:
> > https://github.com/fastlane/fastlane/labels
> > https://github.com/ionic-team/ionic-cli/labels
> >
> > Or pretty extensive lists of stuff:
> > https://github.com/Microsoft/TypeScript/labels
> > https://github.com/Microsoft/vscode/labels
> >
> > What do we actually need for the beginning?
> > Any other input?
> >
> >
> > Does anyone have an idea how we can "manage" our labels across our ~70
> > repositories? Are there any scripts out there that can automate the
> > creation/deletion of them via the Github API?
> >
> >
> > Best,
> > Jan
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [DISCUSS] [Github Issues] Issue and Pull Request labels
Posted by ra...@gmail.com.
Labels that I would like to have:
- something to show that you are open to suggestions or want to work out
how something is supposed to work. Could be "discussion"
- A "Work in Progress" label
I would have tried to just write a script that creates the labels via GH
API. But do we have the necessary permissions to do so?
Jan Piotrowski <pi...@gmail.com> schrieb am Do., 9. Aug. 2018, 23:07:
> Now that we have Github issues enabled for all our repositories,
> another new thing we have to talk about are Github Issue and Pull
> Request labels.
>
>
> If you are not aware of Github labels, here is a nice introduction:
> https://help.github.com/articles/about-labels/
>
> This also contains a list of the default labels all our repositories
> got when issues were enabled:
>
> > bug, duplicate, good first issue, help wanted, invalid, question, wontfix
>
> https://help.github.com/articles/about-labels/#using-default-labels
>
> Issues also have a color, which - when chosen well and used uniform
> across repositories - make it easier to scan the issue list.
>
>
> As we come from JIRA, it's important to understand the differences.
> A JIRA ticket has many different fields: Type, Status, Priority,
> Resolution, Affects Version/s, Fix Version/s, Component/s, Labels,
> Security Level, Environment, Estimate, Flag, External issue URL,
> External issue ID, Epic Link, Sprint, Docs Text
> On Github none of those exist. Most of this information has to be
> supplied via the description of the issue (and can be requested via
> the issue or PR template, see previous email), but it can also make
> sense to map some of those via Github labels.
>
>
> With the first few issues that came in on our repositories, I already
> created the following two new labels:
>
> - `support` - Used for support questions that don't report a bug and
> don't request a new feature but e.g. want to understand how something
> works, need help debugging their individual problem etc. (This will
> probably be the majority of the issue we are getting.)
> - `platform: android` (ios, browser, windows, osx) - For plugin
> repositories it makes sense to categorize e.g. a bug report or feature
> request for its platform
>
>
> Other projects have very structured labels:
> https://github.com/fastlane/fastlane/labels
> https://github.com/ionic-team/ionic-cli/labels
>
> Or pretty extensive lists of stuff:
> https://github.com/Microsoft/TypeScript/labels
> https://github.com/Microsoft/vscode/labels
>
> What do we actually need for the beginning?
> Any other input?
>
>
> Does anyone have an idea how we can "manage" our labels across our ~70
> repositories? Are there any scripts out there that can automate the
> creation/deletion of them via the Github API?
>
>
> Best,
> Jan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>