Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Enhancement] Specify issue title / body #6

Open
geekdave opened this issue Nov 23, 2016 · 4 comments
Open

[Enhancement] Specify issue title / body #6

geekdave opened this issue Nov 23, 2016 · 4 comments

Comments

@geekdave
Copy link

geekdave commented Nov 23, 2016

Would you be open to an optional configuration that would allow specifying the issue title/body instead of defaulting to the more generic Update from #xyz title?

i.e. if my Slack message was Need Code Coverage / We should hook up code coverage to this repo using codecov.io

and then I reacted to that message, then the bot would create an issue with:

Title = Need Code Coverage
Body = We should hook up code coverage to this repo using codecov.io

This could be an opt-in behavior with some config like "useMessageText": true, such as:

  "rules": [
    {
      "reactionName": "evergreen_tree",
      "githubRepository": "discuss",
      "useMessageText": true
    }
  ]

With regards to the discussion in 18F#41 - If this were an opt-in behavior via config, then users/teams could agree to the implications.

I'd be happy to PR this myself, as long as it was something that fit your vision of the project.

@mbland
Copy link
Owner

mbland commented Nov 28, 2016

Hi @geekdave, just now getting back to this after the holidays.

The original use case for the plugin in general is that people will say something "important" in Slack, perhaps not anticipating doing so in advance, and someone then tags the message after-the-fact for efficient triage and cultivation of the content (and without exposing any potentially sensitive information). So I'm wondering, if you're deliberately writing a GitHub issue in the Slack message, why not just file the GitHub issue directly? Not saying "no" to your feature outright, just still trying to understand what makes it a compelling use case for you.

If you wanted, you could fork the project and get a prototype running, to see if it proves as useful as you think. I'm about to post the new mbland/slack-github-issues repository soon, which contains some architectural changes, but I don't anticipate a (nasty) conflict were you to proceed to hack on a fork of this repo first and then patch the new version with the changes.

@geekdave
Copy link
Author

geekdave commented Nov 28, 2016

Hey @mbland - Thanks for your thoughts here. I'm admittedly quite new to Slack bots, and I'm probably in a bit of the "when all you have is a hammer, everything looks like a nail" phase. I work on a distributed team, and we spend all day in Slack. One common thing I see happen is a few of us are brainstorming via chat, and someone has a light-bulb idea. Then someone says "can you file an issue for that?" Then one of two things happens:

  1. The person files the issue
  2. The person is in the middle of something else and doesn't get around to it

My thought when I saw this project was "oh, perfect! now the person suggesting the issue should be filed can actually cause the issue to be filed!"

I get that with the current behavior (simply logging a link to the slack archive as the issue) that we can ensure the pointer to the conversation isn't forgotten. But my worry is that if we adopted this practice, we'd wind up with a sea of tickets that all look identical, and the task of grooming them later would become daunting.

I appreciate that your use cases may look different from mine, based on how your teams operate. So I'm happy to kick the tires on this in a fork, and we can stay in touch about how it works out. Sound good?

@mbland
Copy link
Owner

mbland commented Nov 28, 2016

Sure, sounds good. One more thing to consider, though: When you add an emoji a message, the bot responds in the channel with the issue that was created for that message. So you could click that issue link and update it right away, rather than triaging later.

@mbland
Copy link
Owner

mbland commented Dec 1, 2016

@geekdave Just getting back again after a quick trip from London, had more thoughts just to keep this going with more context.

So the original use case for the plugin is that people would flag content across any number of channels, not all of these folks would be technical, and dedicated content folks would then later do the triaging, then edit and integrate the information into the proper documentation. In other words, it was a tool to make these content folks' job easier.

But, obviously, there are many more applications. 😄 In your case, if folks are mostly just filing technical issues and not worried about confidentiality, an option to include the message text in the issue body would be totally worth it, I think.

Having a parseable format for an optional issue title seems like it might be useful; the question is what format makes sense. I'm thinking something more like:

"My issue title": Need to fix the world
'My issue "with some quotes" and escaping \' characters': Fix all the things!

I'm thinking the trick here is that the first character is " or ', and the end delimiter is ": or ':. I think that would be relatively natural for both humans and machines. Thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants