Add labels to a story even if you don't have write access to the repo about websiteone HOT 5 CLOSED

Looks like we could use:
https://github.com/ssaunier/github_webhook

to listen to issue creation events and then

https://developer.github.com/v3/issues/#edit-an-issue to update the issue with labels pulled from the content.

If only my ruby was up to scratch :)

Next thing is how to identify labels in the text - # and @ are already in use so something else:
@@Label? ##label? $label?

And do we want to remove the labels from the body of the issue afterwards or leave them in?
A compromise which may make sense is: if the last line of the issue is just labels then pull them out of the body of the issue, otherwise leave them (maybe they are in the body of the text and make sense there)

from websiteone.

@freeranger said in slack

I forked the repo but I don't see issues in my fork, only if I go back to the main repo. I don't see a way to assign the issue to myself
I wouldn't open a pull request until I had something to push to the repo though, which I don't because I haven't done more than the investigation bit so far....
It seems wrong to me that I can create an issue but I can't say "this is a bug" or whatever, which is what the labels give.
It's down to the core team to triage every issue to classify them.
If have thought bugs should get more of a look in than enhancements generally but how do you know what it is if it hasn't been labelled as such?
If you think this is a bad idea then I'll just bin off the issue....

from websiteone.

@freeranger you wouldn't see the issues in your fork. There is no way to explicitly assign yourself to the issue. There is the waffle way which I am trying to get you to test, which is to start by making a branch with an ID number of the issue. That's something that waffle uses to automatically assign you to a story.

You're right it's early for a pull request, but you could open one that was even just a documentation edit. It's never too early to start on a pull request.

I don't see a problem with you not being able to assign a label. You can write "I think this is a bug" in the text, and then the core team can evaluate that.

I think the idea that Github has built in is that one has a core team that does that assessment. There's no record of who adds which labels. A label added by a user could be assumed to have been added by someone who understands the codebase and thus could cause confusion.

You ask how do we know if something is a bug or enhancement if it is not labelled as such? And the answer is that the core team makes that assessment, while the user can use the text description to assert what they think, but the core team knows that if a label is assigned it is a classification by someone who knows the codebase and thus has a different level of reliability.

Make sense?

If you want to get involved in the coding we could move you into the core team. If you're operating as an interested user, then I think it's reasonable to leave the label adding ability as something that you won't have to worry about.

Of course I'm open to other opinions ...

from websiteone.

@tansaku - I don't know what you mean by "Making a branch with an ID number of the issue" - do you mean that in my fork of the repo, I create a branch and name it IssueID_Something_or_Other and waffle will then assign it to me?
I definitely can't create a branch in the main repo.

If the core team are happy to spend the time triaging the issues then I guess that's fine - just trying to make it easier to give issues the correct visibility (should they all be marked up for grabs for example?) but I take your point about not necessarily trusting a label assigned by some random person...but then you allow them to create an issue in the first place so you are sort of trusting them there - someone at some point still needs to look at it.

Perhaps people creating issues, which you are trusting that they believe what they write, can label the issues as they see appropriate. At some point a core member triages the issue (guided by the labels the reported to choose which ones to look at with the little time they have on their hands toda y - e.g. potential bugs get a look in before enhancements) and, if they agree, they add a "verified" or "accepted" label (which only core people can do) so that other core members know it has been looked at and is kosher.

Also, I can go into PT and label away to my hearts content, so there is somewhat of an inconsistency there - is this because I am a "core" PT member or does PT just trust it's users more? :)
it would be good if we had a reasonable set of consistent abilities across the board, even if that meant taking away some abilities (restrict who can label issues in PT) rather than adding them to other products (allow labelling in git/waffle)

At the moment I am just an interested party, but even if I had code to contribute, that doesn't mean I belong in the core team.

from websiteone.

after review we're thinking that project maintainers are the ones who should be setting the labels on issues

from websiteone.