I think we should not focus on one, but instead make Codidact a specification and have multiple implementations adopting it. The “best” MVP can then finally be officially “advertised” and be “the” Codidact implementation.
What exactly would the specification you envision entail? That is, what would be specified, and what left for the implementation?
2 Likes
The specification is our current documentation.
It specifies - in detail - how the service should work, and may even give implementation advice.
In that case, I don’t see the point of your suggestion. Our goal is to provide an implementation. Of course anyone is free to implement the complete specification on their own (it’s freely accessible, after all), and if that alternative implementation is finished earlier, anyone is free to suggest to use that instead of the officially developed implementation.
But I don’t think it makes sense to officially implement several versions concurrently; I believe that would only slow down development.
I thought you maybe thought about splitting into relatively independent parts with defined interfaces, so that those parts may be developed independently. That might possibly have made sense.
7 Likes
The good part about this is that it would create a sort community vote, combined with a handicap for languages that are slow too develop.
However, there are a bunch of issues, too.
A) splitting up our resources.
As a voluntary project, there’s not that many dev hours to begin with. Say there’s a bunch of people who can work in C# and another language.
Say there’s projects in 10 other languages.
Say per language there’s 2 devs who would - given the choice - prefer the other language.
That’s 20 devs who are currently contributing to a common goal, which would otherwise be diluted into smaller projects.
B) Discussion explosion
Currently we discuss a list of things. With several languages, we’d be discussing a matrix of things.
As an example, consider the relatively recent discussion about having the option of having page strings translated. In C#, per a de-facto standard you have the option to translate things anyway. That pretty much resolved the main discussion point, except there’s one alternative for more complex translations, like multiple plurals in Polish etc.
Now imagine this discussion if you had to find a solution that fits 10 different programming languages.
Plus, retrospective for things that have already been decided.
C) Kill the living document
The spec is not final and can still be adjusted to findings from developing the codebase. If you want to prevent (valid) discussions a la “but the PHP guys already have it that way” for every change, you’ll have to go full waterfall. Write a complete spec up front; not just for every screen, but for every button.
And devs LOVE to do that, so it’s gonna happen super fast in an all volunteer project. /s
2 Likes