Wire Extras repository?

[Anticept]

Many people were saying that the wire SVN has been a bit stale, with updates slowing to a crawl. Many have also asked if things posted to the wire addons should be added to the SVN as well.

I personally object, I would rather have the wire team choose what should be ported into the official SVN. Remember, for every tool that they put in there, they become responsible for it. This tends to take away valuable time for important functions.

However, I also love the SVN download concept, so I would like to post this: I have a subversion repository already set up that I have been experimenting with, and would like to start a "Wire Extras" repository. I would like to ask if the wire team would make mention of an "Unofficial Extras" should people decide to download the extras. I would like to see a group of people test and evaluate community contributed projects, and commit them if they are deemed worthy.

Of course, should such a project be undertaken, we would need some rules of our own. So far, I am thinking the rules for inclusion of extras are following:

1. Cannot conflict with any existing official wire addon, nor any other addon from the extras repository. Should a conflict develop, it must be fixed immediately or risk removal (or placed in a broken branch should someone decide to try and remake it).
2. The functions and use of the items going into the repository need to be well documented (does not apply to the lua code, just the in-game item). There is no excuse for skipping this important procedure. It is not right to force other people to try and figure out what you were trying to achieve. Documentation can take form of a readme at minimum. Sorry, but in game help is just too sketchy, therefore does not qualify. Neither does the garry's mod wiki (it just isn't smart to rely on documentation in a wiki not owned by the project).
3. All work cannot have an exclusive copyright. Wire is a group project, which means people should be allowed to use your code at any time, so long as credit is given.
4. Modifications to someone else's work either needs to be submitted to them, or take form in a NEW tool. We don't need to be spending hours arguing over who and why altered two lines of code.
5. (Ties the last two together) Ownership of a tool or project cannot be transferred. If someone were to be hospitalized for a month, then come back to their project which was rewritten from the ground up, it will cause a lot of friction. Again, make and submit a NEW project, and it will be re-evaluated for inclusion.
6. Contributors take responsibility for what they commit.
7. Cannot commit anything which supplies or relies on a DLL.

Thoughts? Would this kind of project be welcome?

[Ergzay]

#1: I agree.
#2: I agree but you might want to clarify what you mean by ingame help.
#3: You should actually be saying something more specific. Wiremod for example is under the GPL (GNU Public License).
#4: You should also allow permission by the original author.
#5: SVN is for proper development. I suggest allowing submission of patches.
#6: Might want to clarify.
#7: Completely agree.

[Jaded Misanthrope]

1. Naturally.
2. See above.
3. Not too hot on copyrights and such, but that seems okay.
4. Yes, or with permission.
5. Sure, I guess.
6. Makes sense to me.
7. Yes.

All in all, I'd love to see this idea go forward--it's really irritating to have to hunt around for Wire addons if (for whatever reason) I lose them.

[Syncaidius]

1. I Agree.
2. I Agree.
3. Seems fine to me.
4. Yes
5. Sure
6. Yes, although what if someone else re-writes it, does it become the new persons responsibility?
7. Definitly Agree.

[Anticept]

To answer questions:

Another big reason why (unless with permission) that a new project should be started rather than just modify an old one, is that it also avoids who should be taking reposibility for an addon, each person basically is responsible for their own work. Patches with permission will be accepted, as the original author is still assuming responsiblity. Finally, if we force new projects to be formed, it prevents clashes with different ideals. In the simplest example: One person may thing that a thruster should have just an on input to keep it simple, while another person thinks it should be complicated, with thruster force, power up time, etc. This method allows people to chose which version they want to use. Of course it won't be so cut and dry, but at least we have a standard.

Second, reponsibility for commits means that if a person commits code which is under a different copyright, and it causes any trouble for the project, they take full responsibility for the consequences. Remember, this project won't give contributor accounts to just anyone who asks, that would be stupid, so the committers need to watch what they commit.

I am looking at the GPL as use for the licensing terms, just want to make sure it does not chafe with the idea.

[Ergzay]

You know, we don't have to reinvent the wheel. The Open Source community has been doing this for decades. You have a select few being admins, more being maintainers who look over their sections, and allow the submission of patches from everyone else. This is normally done via a mailing list, but this could also be perfectly well done via a specialized forum or section in this forum.

[Anticept]

Indeed. You still should always have a "ground rules" bylaws to abide by in ANY open source project.

[Anticept]

Unless there is a greater demand for this, I really don't see that this is wanted.

EDIT: I have decided to go ahead with the project. We will see how it works out.

[cpf]

Might want to vet new contributers before you give them SVN access

[Anticept]

Yes, I will be making sure they understand how to use SVN before giving them access, and only to trustworthy people. However, it's next to impossible to do permanent damage, as it takes snapshots of all changes. Unless they somehow corrupt the filesystem itself, I can just look at the logs and delete their access, then perform a rollback .

EDIT:
Released! http://www.wiremod.com/5216-unoffici...xtras-svn.html