SRL Archive - MSI Archives

Hello everyone; I thought I'd be discussing this with the SLs, but I changed my mind and thought the community should have a say.

The issue we have at hand is:

Quality vs Contributions (& quantity)

How / Why?
http://villavu.com/forum/showthread.php?t=57248

nickrules started to contribute a lot to MSI. As is understandable, his code is not of the same standard as the MSI SLs who did most of the bulk until now.

Now here's my thing:
The code could be allowed into MSI after the SLs have reviewed it and probably re-written parts of it. However, this would take a lot of freedom from the SLs and anyone who wants to contribute as they'll have to have their code re-written and so on. The only advantage of this is that it keeps the quality standards up.

Situation 2:
The code is allowed into MSI after checking that it compiles and interacts properly with the script flow (this is necessary for it not to screw up). However, it won't (necessarily) be completely checked for failsafes, possible screw ups, perfect looping and so on.
It would be added to MSI, and whoever wishes to use it, can. If someone wants to use it and feels that it is not quite up to their necessary standards, then they can just edit it.

The risk with this is that a lot of not great code will be put into MSI, diminishing MSI's reliability. (Which would really suck).

However, with ensuring a minimum quality, it could be done. And hopefully people will be learning a lot and quickly through MSI (and barebones) so the quality will be kept up.

Scenarios:
1. Slower development, Quality assurance
2. Faster development, Quality at some risk

So what does everyone think?

I think I like scenario 2, although it has its risks and will need to be well managed.

I will be wanting to hear the SLs thoughts in private, as they would be the ones taking the biggest toll from this decision. But with GIT, this sounds promising ;)

~RM

The patches and/or code submitted should definitely be checked either way. From there, I think it's really up to the people doing the development (SLs I take it) to decide whether or not they want to make sure it's completely up to their standards or just make sure there aren't really any issues with it before allowing it to be merged into the include. It could be a lot of work for those people in charge, but the quality of the include depends on how much work they want to put into it.

I would go with a mixture, method 2 with some re-writing if needed.

EDIT: I flip flopped.

I'm going to go with scenario 1 actually. Initially I thought that scenario 2 would be better because it would encourage more participation in general, but I think if the SL's have the time, having them review the code and giving people feedback could potentially be better for people to learn that just submitting code that doesn't work as optimally as it could. The less experienced people would then have more interaction and explanation from people with better habits, more experience etc. and there's a trickle down of knowledge from the top.

Ideally, those who started off not knowing a lot would learn enough to the point where they could then help others and so on.

Tim0, I believe the learning will come more from scenario 2.

By allowing not optimal code, it can then be modified and explained & discussed along the way. If SLs are just going to re-write it there will be a gap.

crap code - working code - ok code - good code - great code

scenario one sort of skips from ok code -> great code without passing by good code, meaning that the 'good code' knowledge is lost.

~RM

From: Rasta Magician
Tim0, I believe the learning will come more from scenario 2.

By allowing not optimal code, it can then be modified and explained & discussed along the way. If SLs are just going to re-write it there will be a gap.

crap code - working code - ok code - good code - great code

scenario one sort of skips from ok code -> great code without passing by good code, meaning that the 'good code' knowledge is lost.

~RM

Ah ok, then I shouldn't have edited my previous post. I was under the impression that under scenario 1, the changes would be made, but the people who wrote the original code would be informed of the changes and why they were made by just the SLs, whereas with scenario 2, I thought that anyone who saw a better way to do it would make little changes and it would be harder to coordinate feedback with multiple changes happening from multiple people.

I guess that doesn't really make a whole lot of sense now that I read it, but that's how I had it in my mind when I edited my post before.

So, to make it clear: I support method 2 :)