We should have at least some option that lists all projects managed by slacker. This would allow users that are approaching slacker to understand what all of the projects are and which ones they could potentially join.

It would be a fine and dandy thing to create some simple unit tests that exercise some % of the core functionality of Slacker.

It would be good to have a visible slack-trail of slacker activity that people could optionally subscribe to (i.e., a channel where slacker activity is shown publicly). This could even be an opportunity to really "show how the sausage is made", if one were to get clever...

All slacker commands should look like the following:

/slacker <paramN+1....>

While we organize people into projects via configuration, users themselves might want to filter (focus) their attention on specific projects or resources. I could imagine this being implemented as such:

/slacker filter projectname1,projectname2

and to remove all filtering
/slacker filter none

We intend on piping new Onboard requests to a private Slack channel for monitoring using Slacker (as opposed to direct airtable integration).

Right now we do really dumb notifications from airtable that do not leverage the "Actionable" notification feature of slack. Investigate how this might be used for maximal benefit.

Find a reasonably good elasticsearch (currently supported) client library and integrate it into the project.

omg surely this can be considered excessive - at least add a 'stealth mode' option

The current config looks like:

name: HQ Engineering
description: HQ Engineering stuff for Hack Club
maintainers: [faisal, graham, josias]
channels:
  - name: infra-alerts
    id: C05G25Y9M6V
    sla:
      responseTime: 1h
  - name: hq-engineering
    id: C05SVRTCDGV
    sla:
      responseTime: 1h
repos:
  - uri: https://github.com/hackclub/slacker
    sla:
      responseTime: 1h
  - uri: https://github.com/hackclub/infra
    sla:
      responseTime: 1h

Consider tacking on the following, to also allow monitoring/responsibility for another project - thus we could have a hierarchy of sub-projects under one governing project:

projects:
  - uri: project://dns

One thing to consider is whether or not it's a good idea to allow any sort of cyclical dependencies, perhaps that should be validated and PRs rejected if that occurs...

Currently the assignment field doesn't display when you do a /slacker gimme, or in /slacker me. It should.

In the same way that /slacker list allows you to list by specific project and other filter criteria, so should /slacker gimme. This is important because I may want to work on one specific project at a time.

An AI clawback policy should be universal in slacker. Any AI that is non-snoozed, and assigned to a specific individual for greater than 2 business days should be automagically unassigned. It might be good to send a notification to the user whose issue we clawed by with a warning as to why, and suggest they could reassign back to themselves if so desired...

hackclub/scrappy#110 - Closed last week

In slacker today:

In my experience I never snooze for less than one business day - I think it would be a good default, and would save many repetitive unnecessary clicks w this logic.

We intend on piping new Blot requests to a private Slack channel for monitoring using Slacker (as opposed to direct airtable integration).

We should allow for having both high-level (project-wide) ownership, and also specifically at the resource-definition level. This allows delegation of responsibilities across larger projects, including support (and specialized support).

Example (excerpt from sprig-platform config definition):

...
  - name: sprig-platform
    id: C04S1A8NT44
    owners: Graham, Fayd
    sla:
      responseTime: 24h
...

Pressing 'resolve' on this issue results in no confirmation from slacker that the work was completed (unlike slack, where I get a msg confirming something happened)... results in me assuming it broke

This may change in the future, but we want Slacker users (both high-level names to be used within slacker configs, and slack/github info) defined in one centralized config file.

All users within project configuration files should use the high-level, human-readable names as opposed to slack/github IDs.

It may make sense to make this more database-driven w/ associated web UI in the future...

The UI of the multiple AIs blend together a bit as seen here:

It would be better to clearly separate them via some sort of hr.

Added the project but never see anything show up in /slacker list welcomers

We intend on piping new sprig requests to a private Slack channel for monitoring using Slacker (as opposed to direct airtable integration).

I attempted to authorize github and it failed:

Please add a high-quality readme that summarizes the project, invites participation, and describes local setup.

I already logged into github!

Productionize #55

For instance, issues with "good first issue" tags could be assigned out to any random person, regardless of them being officially (configured in config) a contributor

Per our discussion, it sounds like you already know what's going on @faisalsayed10

preferably via a dropdown picker or something that autocompletes

Sometimes I want to be in community-support mode and focus on Slack work, sometimes I want to be in white-hat PR review mode, and sometimes I want to pick up a trash bag and clean up some bug reports or feature requests.

Very broadly, slacker should respect the type of work that people desire to do (or review).... filter types at this point could be slack, issues, or code? Use cases that should respect this:

I want a new piece of work of worktype
I want to see work on this project of worktype
I want to see analytics on worktype

There may be cases where we would like to route specific questions to specific individuals with specific domain knowledge/expertise. As such, resources defined in projects should support pattern matching of content to route specific work to specific people. If no resource-scoped responsibilities are defined, the ownership hierarchy should be respected (defaulting to project-level owners).

Example (excerpt from sprig-platform config definition):

  - name: sprig-platform
    id: C04S1A8NT44
    owners:
        default:
            people: Fayd
        specialized-web-responsibility:
            people: Graham
            pattern: /^(https?:\/\/)?([\da-z\.-]+)\.([a-z\.]{2,6})([\/\w \.-]*)*\/?$/
    sla:
      responseTime: 24h

Note: The above yaml is purely explanative and should be interpreted as pseudocode - do not take this specific example as exactly how we should implement this feature, find something that works 'good enough' and is clean.

It should not be the brightest, shiniest button on screen - that begs for it to be pushed.

At least one new document should be uploaded to elasticsearch for every AI in slacker. See #58 for details on what this document should look like.

It may be smart to implement this in a backfilling-friendly in cases where we want to refresh a project's state in ES....

Please add instrumentation to the slacker service.

1. Response times & success/failure for all commands
2. Response times & success/failure for all db operations
3. Counter that increments when service starts up
4. Response times & success/failure for all external API calls (github, slack)

We should support something like this syntax:

/slacker reopen <action_item_id>

write the getting functionality for /slacker get [id] command

There may be cases where someone does not have sufficient skills (or time, or whatever) to resolve a work item. For these cases, you should be able to assign one of your work items to another specific individual - for instance:

/slacker assign <workitemid> <username/email?>

Please create a beautiful, useful information-rich dashboard that utilizes instrumented data from #18.

When users click the 'resolve', 'close - irrelevant', or 'snooze' buttons, we should probably display a modal popup that includes a radio input or dropdown menu that allows them to categorize why they pressed that button. We could investigate the utility of having there be a free-form text field there as well.

This data would be especially helpful when looking at analytics and determining what we could automate.

In attempting to work through the sprig queue, there are many repeated work items. Items that we hit 'resolve' on should not show up in subsequent calls to /slacker list.

Proof that this happened:

Whenever you hit the "Resolve", "Snooze", "Close - Irrelevant" buttons, the work item being displayed should be removed from the slack user interface.

This results in a) good feedback to the user that their operation was successful and b) ensures that the user does not lose context/place (for instance, forgetting they already dealt w/ something already)

This would, for the target input user, display a summary of all responsibilities in whatever form is most effective and explanatory/practical/good. For the current user only (not allowing for snooping on others), it could factor in current filter settings and other relevant status into its output to be helpful to the user - if not with this functionality, then "where" I guess would be my question...

I could imagine the slack command looking thusly: /slacker whatsup (user) <- parens indicating optional user param, defaulting to self, or the more boring /slacker duties (user)

We should keep track of github tags associated w/ issues such that we can serve 'good first issue' things to new contributors that aren't officially associated with a project (see #39)

Please add reasonable alerts in grafana for Slacker on top of instrumentation from #18

Add a comment here to this issue with the specific schema(s) we want to store in ES for slacker analytics purposes.

This asks for access to perform actions on your behalf - per our discussion, we both think this is probably not necessary? Please investigate and remove that if needed/is practical.