Progress: why it's slow, and what we're doing about it

Announcements
1

We’re not moving as fast as we’d like to. Why? What can we do about it?

Two weeks ago, we had a meeting among Codidact’s leadership: leads, group leaders, and admins. It was called for a number of purposes, but principally it was because we haven’t been making enough progress and needed to find a solution.

There were, as we saw it, two options:

  • Continue with C# core development and try to spur progress somehow (how?)
  • Move to developing QPixel into our vision for Codidact MVP and come back to C# later.

We had a bunch of good discussion about this, including looking at ways to spur progress on C#, and ultimately it went to a vote, which came out as 5:3 QPixel:C#. @MasonWheeler and @luap42 generously volunteered to make another effort to spur progress and get us to a particular point by April 4th - today - so we adjourned to let that effort play out.

Now, it’s April 4th. We’ve seen some more progress on C# core these last two weeks, which is great, but ultimately it’s not at the point we aimed to be at by now and isn’t likely to be in a reasonably short timeframe. That makes the decision for us.

We’re going to move forward with developing QPixel to our MVP standard.

We’re doing this primarily because we think it’ll get us to MVP faster. We’re not doing this for reasons of tech choice: Rails is not better than C#, and vice versa. QPixel is further along in its development, which should mean that migrating it to use our MVP spec doesn’t take as much work as developing from scratch, because all the groundwork that we’re currently bogged down in is already done.

I’m going to be going round today talking to specific folks who are affected by this, but please rest assured we’re not throwing our progress away. This decision is intended to spark progress by building on a more active project that’s already further along, not to pull the rug out from under people.

What we’re not going to do is stop any development on C# at all. We’ve got some talented developers working on our C# solution who may not be able to switch to Ruby, and it would be a waste to leave them with nothing to do. Practically, this decision is likely to run more like running both solutions in parallel - development on C# will keep going, just with the pressure taken off, giving the team the time to make sure it gets done right.

The work our docs and design teams have been doing has helped make this decision easier: we have a solid spec and database schema, and we’re working on use cases and wireframes that solidify what we’re working towards on both projects.

If you have Ruby/Rails knowledge, or you want to learn, there’ll be a list of tasks up on the QPixel repo soon that you can get stuck into. If you have C# knowledge, you’re still more than welcome to contribute to the C# core solution. I’ll be making some lists of who’s responsible for what available soon, to make it easier to find the assistance you need to contribute.

I know this seems like a big thing out of the blue, but what we’re hoping for is not a huge change to our processes. What’s already going on will keep going; we’ve already got QPixel running communities as a stop-gap, so what we’re doing now is a simple switch from maintenance mode on QPixel to active development towards MVP.

12 Likes
2

I want to amplify one point: we’re not throwing the C# path out. Ultimately I expect to end up there; the team chose that stack for a reason. But it’s a slower path, and we need to get to MVP functionality sooner. At some point in the future I expect us to cut our operational sites over from the Ruby-based implementation to the C#-based implementation, which should be seamless for users other than a bit of downtime for the switch.

So if you’re working on the C# project and can’t or don’t want to work on the Ruby project, no problem! Please keep moving the C# project forward. The pressure’s off, but the project is still important.

3 Likes
3

Suggestion, which may or may not make sense - and I am not currently in a position (based on existing knowledge/skills for either C# or Ruby, and lack of time right now to learn either one well enough to be a major contributor at this time) to implement, but just for your consideration:

Since one of the key differences between QPixel and the planned C#-based Codidact is the database separation (both authentication vs. community data and also separate vs. merged database for communities), maybe it would make sense to, once the C# system has a functioning production-level authentication database (maintaining the master shared user list, passwords, email addresses, etc.) to then change the QPixel authentication/login system to use that database. It would provide a way of transitioning a piece of the system and potentially allow for later side-by-side running of QPixel and C#-Codidact instances sharing a master user list.

6 Likes