https://futureofcoding.org/ logo
Join Slack
Powered by
There was a question recently asked in <#C5T9GPWFL...
# administrivia
i
There was a question recently asked in #C5T9GPWFL that I'd like to use as a discussion prompt. The poster has since deleted the question (see comments in this thread), but here's the text of the question for reference:
How would you recommend implementing an extensive and large rest api specification? It will include lots of special operations such as negation and logical AND all specified via characters that special meaning. There is no formal grammar, only pages of docs with scattered rules and schemas. Example query: "/user?name:not=joe&alex"
This feels like a very "present of programming" line of inquiry. It feels like something that'd be posted to Stack Overflow. To me, it doesn't pass the sniff test of on-topic-ness for the community. As the community grows, I think we can expect more things like this, and I'd like us to have a good strategy in place to maintain our focus. There are no shortage of other general programming communities, or technique/technology-specific communities, that address the present of programming. We're all here because we are unhappy about the present. It's necessary for us to talk about the present, so that we can understand what's wrong with it. But I don't think we should facilitate or normalize conversations that have no eye on the future. • Do you agree that this example question is too far from the core focus / purpose of the community? • If so, how should we handle these sorts questions when they come up?
👍 2
[moved from top level, originally by @Drewverlee, who wrote the question I've quoted above]
@Ivan Reese i understand your response. I'll elaborate and let you decided if its on topic or not.
I wanted to ask the question without leading anyone to a particular answer. I'll be more direct. http://hl7.org/fhir/ is an API specification that roughly would be 60 some odd pages when printed.  Clients send you commands according to that specification and you must implement executable code for it.
Today, i imagine most servers manage this through traditional programming which would amount to a considerable amount of conditional logic. An approach which i believe would very complicated. successful progress means dragging the past forward not abandoning it. I'm curious what the future of client server communication might be would be and what might be done to transition current systems to what ever that vision is.
My personal way to view this is as a compiler problem. There is an adhoc spec, but no grammar, tokenizer, parser, ast builder. But my experience in that domain is very limited.
Another question might be, what tools will we have in the future for reducing the noise such documentation has into more meaningful categories. A strong argument for Type theory is that it presents a constant way to interperated functionality. What tools do we have to go from the tangled mess of overlaping concepts that world presents to the more compact understandable one present in say category theory.
[moved from top level, originally by @Ray Imber]
@Drewverlee I understand your desire to not bias any answers, but there is a fine line between trying to be "non-leading", and being too vague. I think you missed the mark here. The context you provided here completely changes the nature of the question.
To be more specific. Your original question didn't carry any cues or connotations that would suggest that you are looking for a "future of code" response.
I can see that you might assume that context already exists because of the focus of the community, but it's also easy to interpret your question as just being off topic without those extra cues. It's a problem with online communication in general. There is some "lossiness" inherent there.
👍 3
c
Agree, and just move them - moderator's discretion is always in effect
👍 2
d
Given the implied topic of this channel I don't particular see a need to continue here. I'll rephrase my orginal question and try to post it in a more receptive way.
👍 4
i
For other folks reading this thread, let's continue to explore how we might handle cases that feel more "general programming of today" than "hypothetical programming of tomorrow", without hammering on @Drewverlee's question original question. One thing I'm going to be doing very soon (as part of renaming a bunch of channels) is writing a new community page on the website. I want to draw more attention to the rule about replying in threads, and the rule about posting one big message rather than multiple small messages. So while I'm at it, it might be good for me to shore up the wording about what things are on-topic. As for what that wording should be... how we define whether something is sufficiently off-topic to warrant intervention... that's very tricky, and I'd love help with that. And as for what the intervention should look like.. well, just like I now have the 
[moved from X, originally posted by @username]
template for moving messages, it'd be good for us to come up with something that I (or anyone) could say as a "hey, I think this is off topic, here's why I think that, and if you want to discuss this let's go to #CEXED56UR" or some such. And in these cases, I don't think it's worth deleting the posts, since keeping them around (with the intervening message) will help guide others toward on-topic territory.
➕ 1
r
Maybe add a "today of coding" channel? There is a high level of collective understanding about current programming in this community. Not that you want to foster yet another stack overflow, but maybe allow a channel for some form of discussion related to near future topics?
🤔 3
d
Your best bet is setting up a system that encourages people to do that because its what works best for them. Trying to get people to write "one large message" instead of several small ones is going to be hard because thats not how normal conversations work between people. Slack added threads late and their second class, unlike systems like zulip. I'm not a regular here though so my inputs is shaky. i'll see myself out and back to my current work 🙂.
👍 1
i
@Drewverlee Agreed, but with a twist — we have adopted this style of using Slack because it's going to make it easier for us to build additional tooling for the community that will sit adjacent to Slack. So in that way, we are setting up a system that works well for the regulars here. We've explored moving to other discussion systems (including Zulip, which I really like the look of), but the outcome of our voting was to stay on Slack and make the most of it. So we are going to have to fight the platform a bit, but that's the least bad option for us. One of the things we need to learn is how to help onboard newcomers, so that they learn that we have some norms — it should possible to do that, it's just a matter of working through the what and how. You're seeing that process :)
@Ray Imber That's a suggestion that's come up a few times. I'm not opposed to it, but let's take that thought to a different thread.
d
Good thoughts. Your moderation leadership will be key. You could ask Alex Miller how he helps govern the clojure slack. He might have written something up.
🍰 1
i
@Alex Miller Have you written up any thoughts from your experience being a good terrific mod?
a
I'm not a mod there 🙂
it's a community slack, not official
i
Touché
a
I'm in a dozen or so slacks and they are managed with a broad range of moderation styles (I wouldn't classify them as "good" or "bad" they are just particular to the origins and evolving norms of the people that use them). some have explicit coc's and very active mods, some are essentially unmoderated. probably the one with the most concrete coc and rules is doc'ed here: https://stltech.org/
👍 1
i
@Alex Miller That's a very helpful reference. I like "member handbook" as a phrase, and how clearly emphasized it is next to the Slack button and in the signup flow.
y
I think almost anything could be fair game as a starting point for our discussions as long as the poster puts effort into explicitly relating it to the interests of the community. So my intuition is that the focus on moderation should be toward this explicitness being sufficiently present, and not necessarily judging if a topic is in itself “futuristic enough”.
➕ 1
👍 7
💯 2
j
I'd have taken this question in the speculative sense -- i.e. "how would you want to be able to do this?" It ties things to a concrete and present tense idea of APIs, sure, but "how could one make a hairball like this tractable with better programming tools?" seems like a reasonable starting point for an FoC conversation. 🤷🏻‍♂️
👍 2
Open in Slack
PreviousNext
Powered by