On 11/06/06, Matt Todd <[EMAIL PROTECTED]> wrote:
2) I agree that it is both important and pertinent to get the general requirements down for the project, but I do see a need and a benefit to having the architecture forming in the meanwhile. I see how these things can be connected, obviously, but with a fairly flexible architecture it can be easy to expand or change it as needed. If we have the skeletal system in place, we can add the muscle and the skin on as needed. [Read more of my comments below.]
Having just been away on yet /another/ training course in Agile methodology, I'd say this is a classic disconnect of concerns. Sounds like Conrad just want something that works, and can be available quickly -- a rather traditional customer point-of-view. Matt, you're talking about implementation details, which is a traditional Developer concern, but not all that important to the Customer. You don't disagree, you just have different roles. The real answer is "yes". Do implement it well, but also as quickly as possible. This isn't really a point of disagreement.
3) I'll be honest and say that I'm not a big fan of the 'Wikicosm' part, but the Perl++ part works for me. I particiularly like simple names. Maybe we could go with something distinctive, much like 'Joomla' is or 'Drupal', etc. Something different, and not nearly as explicit.
Well, if we can have a "blogosphere" I suppose we can also have a "wikicosm" :-)
Mainly speaking on point number 2 again, I agree that we need to be discussing and deciding on the minimal features, but this is does not mean that the architecture should be poorly designed. Even with a weakly implemented yet well designed base, it would be easier to take this minimal wiki and upgrade it into something very powerful.
I already made this argument in an earlier post, when I suggested a requirement that the accepted solution have a modular architecture (plug-ins, for example). I forget the exact response, but it was something like "whatever". Again, I think Conrad is really mainly concerned with something that works, and quick. The rest is just icing -- correct me if I'm wrong here.
I guess what my very first recommendation (before even a name) is that we have a flexible, well-designed archiecture, preferrably with an MVC pattern, with RESTful-like (URL) mapping, etc. I believe that this will be integral to the successful adoption in the community because it allows for very expansive modification.
Yes. yes, yes, yes...
I will be looking over some other features to recommend. Wherein shall we officially submit our recommendations? Here? And is there a specific way to do so? (This is more of a conversation-generating question.)
This gets to a point thats been niggling me, which is that because of the prize/grant involved there is automatically an environment created which does not reward general community collaboration. Okay, you're talking about requirements there, and that is a bit different, but if I were the sort who /was/ motivated by money I would likely not be motivated to get less of it by sharing. So a prize would seem to encourage a certain amount of go-it-alone-ed-ness, and also (because of the "first done, first won" rule) it would also seem to encourage the most minimal feature set possible. Hence there isn't any reward for community discussions of desired features. That's probably an okay thing if the goal is to get something done fast. Perhaps the community will get involved after that, when it comes time to adding-on? Somebody needs to run with this, but it's risky to think that one could start work on a p6 wiki candidate, only to be pipped at the end to some other wiki engine. So then would we carry on and have 2/more on offer, or discard the work, or give the work to the guy who already has a grand in his pocket? Just some random thoughts there, this thread seems to have gone a bit quiet! --michael
