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 <raphine...@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 <piotrow...@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-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > >
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org