I’m seeing a lot of philosophical discussion lately about how communities should behave – closing criteria, the value of canonical answers (and how to make them happen), what kinds of edits should and shouldn’t be ok, handling obsolete content, and so on.
These are matters for the communities to decide.
We need to focus on designing the platform. In so doing, we need to understand the range of use cases we need to support – the things communities might want to be able to adjust. But we are not imposing policy. I humbly suggest that discussions of what those policies should be, absent the context of and participation from specific communities, are not helpful now.
We have a lot of work to do. We’ve been talking about Codidact since mid-October, and we have a decent (but incomplete) list of MVP requirements and the beginnings of a functional spec (with very little review so far). It’s already going to take longer than some of us want to get an MVP built. Can we please try focus a little more on the discussions that advance that goal?
I agree, but given that so much of the frustration people have with SE is because the UI and community policies are at cross-purposes, it’s really hard to disentangle the one from the other without making the same mistakes.
Here’s a trivial example: people complain about users using comments for the same things that comments have been used for since Slashdot in the nineties. Instead of fighting new users’ familiarity with other sites, if you want that textbox used differently, simply label it differently. (Coming up with a better label is left as an exercise for the reader. )
Features that are left out because they were not envisioned at the early phase are MUCH harder to implement later.
Almost everything discussed is part of the platform and the selected fundamental aspects are key to making it better than SE.
I think having liberal policies for Codidact should be a given if it is to flourish.
If some community wants to restrict users they should purchase a franchise licence and become a paid affiliate site that has some strange draconian rules that do not advance the goals of human knowledge.
Getting bogged down on implementation is a side effect of the technical background of many of the members here who try to envision an implementation to achieve their desired function.
We should (and need to) talk about capabilities we might need to enable. I’m just saying that discussions about how communities should then use those at the policy level, like specific criteria for closing a question or rejecting an edit, should be held by those communities and not by us. We do not impose policy; we provide tools. Separately, many of the same “we” are going to discuss policies for the instance that we host, which should be minimal but not non-existent, but I think that’s a separate, later discussion.
To me this sounds like we need just a small few things:
a timeline which keeps us more organised
a less-than-MVP such that we can at least start writing something (because we run into the danger to be discussing too much and move away drastically from an agile development).
leadership? a ‘head-person’?
The discussions are all nice, but Monica is right, we should start moving on. (also, I start to believe that all the discord and discourse could be reunited very quickly on this new alpha platform)
We have a partial functional spec. I posit that it plus “common sense” (make reasonable assumptions where you need to, and be able to change them if needed) gives us enough to get going. If that’s wrong, what else do we need? Could the tech and team leads weigh in on next steps? Thanks.
I tend to agree. We’ve got a good set of discussion here which serves as a kind of secondary spec if anything isn’t already in the specs in the wiki, and folks can always ask questions if they’re unsure of what should be doing next. I’d say we can get going.
We need someone to create a basic skeleton project, and then the rest of us can start developing on top according to some development process - that’ll be down to @Marc.2377 to pick.
Damn. I’ve been kind of letting this site chill out on the backburner, hoping I could pop in some time (like tonight) and find coding under way. I am disappointed that there isn’t even a skeleton.
It seems, to me, like analysis paralysis. I understand the desire to get it right from the beginning, but I can’t help but feel an opportunity has already, somewhat, been lost. There was a moment when the iron was hot, so to speak, that has definitely passed. That isn’t to say we can’t still do this, but we need to do.
Yes - we (thankfully) definitely have more than enough to get going with actual software development by now.
So, after revising the contents of my conversations with more experienced developers, both on the public Discord channels and via direct messages (and calls), I finally started developing the skeleton project. This happened just a day ago; unfortunately it wasn’t possible for me to dedicate enough time on that earlier.
It’s highly likely that, by next weekend, this skeleton can already be made available for comments and validation by some of our peers, and then it should be just a couple more days until it’s up on the public repositories for the team to work on.
It should also be noted that the team will probably be using a task management tool internally (@ArtOfCode has set up an account on https://clickup.com for us and it looks a good enough tool to me, for the time being) to serve as an organized TODO list and keep track of progress on specific project milestones and tasks. We’ll make that decision over the next few days, I hope, and then the core contributors will be invited.
We’re indeed a few days “behind schedule” (quote-unquote as there’s been no hard-fixed, official or actual schedule), but it’s still quite probable that we’ll have something to show for before the year is over.
)