SRL Archive - General

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

I think we should go with scenario 2. It would be a pain for the SL's to have to rewrite everything (which I'm assuming would happen in most cases), and like you said, slow down production.

I think that as long as the code works, and uses the resources within MSI properly, then it can be added. Of course we'll be looking over the code before committing, but completely rewritting shouldn't be necessary.

I agree with Coh3ns post. As long as the code is up to par and functions properly, and we can just edit little things as we see fit.

Yes (What the other two said :P)

We should have someone assigned as a quality control (or do it as a unit) so that the rest can focus on actually scripting. I'd volunteer to be quality control if you want, since I haven't really contributed much more than advice to the include yet..

For now just accept everything that works somewhat well. If one SL approves of code, it can be modified by said SL and committed. I think fast progress and getting more skills to MSI is very important now.

From: marpis
For now just accept everything that works somewhat well. If one SL approves of code, it can be modified by said SL and committed. I think fast progress and getting more skills to MSI is very important now.

I agree with this as well. We need to maintain a higher standard for MSI code but at the same time the more development we can get through right now the better the communities response will be. I would really hate to think that we spent so much time on something that would continue to not be used.

NCDS, it has started to be used ;)

Also, marpis, you now have mod rights as well.

~RM

Imho, I would like scenario 1, as I think quality is always better than quantity (Few but flawless scripts are better than many not-so-flawless scripts)

From: Zyt3x
Imho, I would like scenario 1, as I think quality is always better than quantity (Few but flawless scripts are better than many not-so-flawless scripts)

We are still the ones who are able to commit. If we don't feel the code is up to par then we either fix it or it doesn't get in.