Brainstorming: Channels usage

[AWegnerGitHub]

At the request of @ArtOfCode- , let's brainstorm some ideas on what we could do with the new Channels feature.

Channels Announcement: https://meta.stackoverflow.com/questions/352065/introducing-channels-qa-for-engineering-teams

Notes:

• We have applied for access to the beta, but do not yet have said access.
• It's worth noting this from @Undo1:

  Re Channels, definitely good to get us to test it out, but don't silo information there. Anything there should be documented somewhere else too.

So...what do you think we can/should use Channels for, in regard to Charcoal?

[magisch]

• Wiki Posts. We should definitely post our SD Wiki there, maybe with a special mod only red tag on it so it's even better distinguishable

• Guidance for review / feedback / blacklisting / additions to smokey

• Technical issues. Again we can have a tag for that and people in charcoal can ask and collaborate on how to build things in there

• Statistics magic and stats reviews. So instead of having these long drawn out chat discussions about stats we can make threads for those there. Remember, we control what's on topic and what isn't.

This is just off the top of my head

[angussidney]

@magisch I'm not necessarily sure that duplicating all of our current wiki and guidance over to Channels is a good idea - remember, Q&A isn't the best way to present documentation, and there's no reason why we should have it in two different places which both need updating.

As for tech support:

• tech support on using Smokey/MS is probably best left for chat - after all, it takes a while to have your access to the channel approved, posting a question, and having it answered - it'd probably be best to just keep it in chat as normal where anyone can get instant help
• questions on developing with all our systems - I think this would be a great place to ask and answer questions like this, rather than filling up chat with them. Also, it will make everything more accessible for people to search for in the future, rather than having to trawl through chat.

Stats etc - I think that's a great idea! For instance, one of our recent discussions ('Why has our average time to deletion decreased over the past month or so') would be a perfect fit for Q&A

---

Now for some other ideas that I've thought of:

• When we made our big meta post on Autoflagging, we had some FAQs which we listed in the post (e.g. 'What stops Smokey from becoming sentient and flagging all teh things?'). We could add these to the Q&A.
• Walkthoughs on how to use the MS write API, websocket, etc

[ArtOfCode-]

In relation to @angussidney's suggestions: I posted a Channels FR for public questions

[SulphurDioxide]

As @angussidney says, I'd like to see the FAQ that we get over and over documented. For example: 'Does smokey miss posts during a reboot?'. I thought that was the case (I think a few others did too) until it Art debunked it...

I also agree that questions on 'How to help develop' would be a nice fit. It's easy for them to get lost in the chat too. I wonder if we could additionally discuss changes to smokey (like the great DB debate) there but possibly that is too meta.

[ArtOfCode-]

So far, nothing is too meta for channels.

[Undo1]

Re 'discussing changes': maybe not too meta, but probably belongs in a GitHub issue. Unless we can sync them together somehow (if someone writes something, awesome), it'd be a good idea to keep those long involved discussions in one place. That's why we encourage GH over chat; I see Channels mostly as a more-structured version of chat.

[tripleee]

My reading of the Channels proposal is that it is meant to be private. Do we really have things we want to keep out of the open, as a community?

[ArtOfCode-]

Private in name, but we don't have to treat it that way - just grant access to people who would benefit from it when they want it.

[tripleee]

I'm afraid I'm skeptical. Unless we can figure out a scenario where this clearly provides something which we cannot pull off with our current communications arrangements, having one more place to keep track of seems like an unnecessary burden.

[magisch]

Private means only that we have to give access.

[tripleee]

Private means it's not open, no matter how widely you give out access rights. It means those who don't have those rights cannot see what happens inside, and there will be a barrier to requesting access by people who might otherwise be able to contribute fruitfully. How do you know whether you want access when you can't see what's inside? Again, I'd like to see a reason why we'd want this in the first place before we start devising workarounds for the problems it introduces.

[ArtOfCode-]

We want this because it's a new thing. Now before y'all call me superficial, that is a valid reason :

• It gives us the opportunity to influence the development of the feature, hopefully in ways that help us.
• It's helpful to the SE team to have a wide range of teams using the thing as it starts, and we're a pretty uniquely placed team.
• Because it's new and nobody had used it before, we don't know if it's helpful to us until we try.

This isn't putting us into any long term commitment to Channels, and nobody's paying for it. If it doesn't work out for us we can ditch it, but it's a chance to try it out and see if we can get anything useful out of it.

[Undo1]

I'd say to try it and see what happens. If we start having real problems with it, address them then.

[DavidPostill]

I agree with Art and Undo. We won't lose anything by using it and we can provide some input into how it works.

The only drawback I can see is duplication of information, but no pain no gain.