Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Blog

Welcome to Codidact Meta!

Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.

Comments on Codidact Technical Roadmap

Post

Codidact Technical Roadmap

+19
−0

Something we've been lacking on the Codidact project thus far is a clear development roadmap. Various people have goals in our heads, and some of our GitHub issues have priorities set, but that's not as helpful as it could be. Developers new to the platform don't know where to jump in, and unless you're also active on Discord, the community at large doesn't know what we're planning to tackle sooner versus later and how pieces fit together. We'd like to address that.

In this post I'll describe some recurring themes that we've seen and lay out a plan for upcoming work. On a volunteer project all plans are subject to change, but this is our best estimate for the main work for the next little while. Of course we'll continue to address bugs, and we reserve the right to add small things that are easy even if they're not on the roadmap. Think of this roadmap as a general outline, not a precise itinerary. You'll also notice the absence of any time values here; we have some groupings and some ordering, but we don't know who will have how much time when, so we're not including any dates. We'll extend this roadmap as we go; assume that finishing up a "leg" in this plan will include sketching out the next one to add to the end.

This roadmap focuses on the code that runs Codidact. We also have work to do in other areas, particularly (a) our communities and (b) some logistics with the non-profit foundation. We plan to talk more about those in future posts. Meanwhile, we've asked each community how we can better promote it, so if you have ideas, please head to the per-community metas and reply there.

Themes

In looking over Meta (including all the per-community Metas), our GitHub issues, and various notes collected in Discord or elsewhere, we've identified some general themes or groupings. We want to make progress in all of these areas in parallel. The broad themes we've seen are:

  • Comforts and pain points: things that are getting in your way or things that are harder than they need to be. Examples: improvements to threaded comments, last-activity indicators on posts, making suggested edits more visible so they don't languish.

  • Curator support: making it easier to tend the gardens of our communities. Examples: tag improvements, improvements to post history, better private messaging between moderators and community members.

  • Other gaps: things we all expect but that aren't there yet. Examples: close voting, network profile, tag synonyms.

  • Expansions: new features or major changes that would help our communities and distinguish Codidact. Examples: filters for the post list, preview from the post list ("quick look", so you don't have to navigate away), better handling of duplicates and related questions.

  • Infrastructure: not generally about the code itself but about performance, resilience, and administration. They're included on the roadmap because they require attention from some of the same people who would otherwise be working on platform code.

  • Community requests: some of these are about code (like community-specific features), and others are about processes (like improving how we do proposals). This is on our radar but not yet addressed in this roadmap. Look for more from our community lead in a future post.

We might have missed some themes, and if so we'll adjust as we go. Our roadmap is a flexible, living document.

Approach

When assembling a roadmap, we think it's important to consider the themes in parallel. It will take us a while to get where we want to go; that's expected. In each "leg" of the journey, we'll try to address some pain points and some gaps while we work on the (generally larger) expansions. Further, some of the expansions will need to be broken down into smaller pieces, which themselves become items on the roadmap.

In other words, we'll tackle larger goals that will really differentiate us when they're done, alongside addressing more immediate concerns that help our users and communities now. We don't want to get so mired in the here-and-now that we never get to the longer-term stuff, but we also don't want to only do the larger (probably more exciting) stuff, either. We'll start the longer-term stuff but also do nearer-term stuff.

The Next Few Legs

In each "leg" of our roadmap, we'll try to make progress in several areas. Because we are a small team, we will generally only work on one major (multi-leg) expansion at a time, though design exploration for one might start as implementation for another is finishing up. We've chosen filters for the post list as the next major feature to work on.

Assume that "stretch goals", where listed, carry over into the next leg as needed.

Leg 0: Upgrades and donation thanks

Leg 1 can start in parallel for people not on the critical path for leg 0.

Leg 1: Predefined filters, address frustrations

  • Filters: initial predefined filters and a UI for choosing one (including setting a default per category). Stretch goal: show the definition of the filter when selected. This last part is the basis of what will be user-editable/customizable filters in the next leg.

  • Curator support: show an indicator when there are pending edit suggestions. Stretch goal: for any category in that community, and unify the suggested-edits review page.

  • User support: ability to expand comment threads in-page.

  • Gaps: basic network profile.

Leg 2: Curation and moderation, user-defined filters

  • Filters: initial definition UI, save filter, add saved filters to selections indicating their community & category of origin. Design a fuller UI and identify any needed additions to search to support it.

  • Curator support: suggested edits for tags.

  • Gaps: finish "last activity" indicator revamp for posts list. (Can start earlier.)

  • User support: address any issues with in-page comment threads, allow changing thread title (with logged comment).

  • Curator support: mod messages that are not warnings. (Can start earlier.)

Leg 3: Robust filters, misc wrap-up, looking ahead

  • Filters: Complete initial feature. This is necessarily vague because we will learn more in the first two legs about what exactly is needed, but I'm imagining a configuration UI with several options (collapsed when not needed) that includes post properties (score, temporal, answer properties on questions) and tags but not yet "stuff about me" (like "questions I haven't answered").

  • User support: figure out how to show reactions in history. Maybe just: when there's an edit, indicate the counts for each reaction type that existed before the edit. We don't need full history, just a way for people to assess currency. (Can start earlier.)

  • User support: expansions to network profile TBD (we assume there will be requests after a basic one is live).

  • Curator support: two-way on-site mod messages. (Can start earlier.)

  • Curator support: for mods, show who deleted comments and when. Stretch goal: comment edit history (rarely needed, but when it is…). (Can start earlier.)

  • Preview from post list: design review and community discussion.

  • Closing and duplicates redux: research, review, discuss.

By the time we get to leg 3, we might have identified other features or major expansions that are more important than the ones listed there for initial exploration. We want to work on the things that most matter to our communities, in an order that makes sense for our developers. If something comes up, we'll of course adjust.

Next Steps

After adjusting our plans for feedback from the community, we've updated (or created) GitHub issues to track this work and created a GitHub project in the main repository to track those issues. You can use that project to track our progress.

If you are interested in working on one of these tasks, please let us know – we'll be happy to assign it to you and help you get set up with the dev environment if you aren't already. Thanks to the people who have already volunteered!

If you are interested in working on something else, that's ok too – there's plenty to do. If you see a GitHub issue that you really want to work on, whether it's on the roadmap or not, please comment on it and say so.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

1 comment thread

Github issues? I thought we used Meta for that ...? (4 comments)
Github issues? I thought we used Meta for that ...?
meriton‭ wrote over 2 years ago

I was under the impression that site issues should be reported on Meta, but now you mention that team uses Github issues for tracking? Is this why the request for bigger code windows has fallen through the cracks?

Monica Cellio‭ wrote over 2 years ago

meriton‭ sorry for any confusion I've caused. We welcome bug reports and feature requests on Meta (especially ones that benefit from community discussion). Some people directly report bugs on Github and that's fine too. We create Github issues for bugs reported on Meta (including per-community metas). I thought we had one for the issue you linked (I recognize it and see that I've previously upvoted it), but I can't find it now so I'll have to track down what happened there. Thanks for letting me know. (I crave an easy way to create two-way links; GH issues link back to the meta posts that reported them so we can update status tags later, and I guess I should start also leaving comments on those posts with the GH links.)

sau226‭ wrote over 2 years ago

We got upgraded to GitHub Team plan a while back, so I guess we can configure autolinking for our main repo.

See https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/configuring-autolinks-to-reference-external-resources for configuration (a repo admin or org owner would need to set up).

All a user has to do after its set up would be to mention a post with the appropriate prefix, and it would be autolinked.

E.g. set up "meta/" as the prefix, with URL "https://meta.codidact.com/posts/" and meta mentions (E.g. "linked to meta/285449") will be auto linked.

Monica Cellio‭ wrote over 2 years ago

sau226‭ it looks like that lets us auto-link from GH to Meta (etc). We're already doing that (though with actual links, not auto-links), but what we're missing is going the other direction. If I link to a meta post from a GitHub issue, it'd be great if something could be added to the meta post (comment or edit) with the GH issue that refers to it. Do you know of a way to do that?