I was thinking about lifting the developer restrictions, and being pretty open to new developers. Basically, turning this all over to the community. Basic thinking is anyone can be developer, but one strike and you're out. This may help spur contributions and development, getting people like kevglass and momoko contributing without having to go through a process to get access. I don't think there is a developer that is regularly contributing anymore, Josh was the last. Hell, I am not even writing Java professionally anymore.
Any objections to a more open policy?
I'm all for it.
Sure, why not… and hopefully the community will grow to develop a process for self directing development.
I'm not sure that this is a good plan. But I don't have a better one, either. Open source projects tend to 'starve', if there is nobody driving it. (sorry for the crappy English, but I think you'll get the point) Ah, well…
Defining responsibilities could help, no? Maybe we should assign moderators for the different boards? (and fix the moderator rights so that is has a technical effect as well)
I'm actually with you Irrisor, but with every other developer moving on with different things, the engine will starve, as you said. Who knows, maybe its time has come and gone. So, might thought is, if there is no longer a central body controlling it, open it up to the world and see what happens. I figure one of the following will occur: A) A bunch of jackholes will get developer access and bloat the library with useless stupid crap. B) No one will request developer access or those who do won't actually contribute and it will starve as normal or C) people will step up and keep it going strong. I'm of course hoping for C, but expecting B.
I figure the policy would be something like: anyone can get Developer access, as soon as ANYONE complains about a developer their access is revoked while an "investigation" is done to see if it should be reinstated.
Also, these guys would not have a Developer title, but something like Contributor (they'll have write access to the repo, but not the level of great distinction. 
Though I definitely see we have a problem, I lean more toward Irrisor. I don't know if this is a good idea. I fear that possibility A. that Mark mentioned will be the most probable case and in the past we've had great problems with overlapping code or duplicate code going into the repository. Hey, I think I was one of the primary ones responsible for this.
I really like Mark's idea of a "Contributor" title, but with a restriction that only "approved" changes can go in the repository. We get a lot of patches in the forum and one of the big problems is one of the developers getting around to applying it to the repository. What if were to give a few highly active members of the forum access to commit to the repository, but with the stipulation that all be submitted in the form of a patch to the ticket tracker on the Google Code site and referenced on the forum first so that any discussion may take place. Perhaps even a poll created to give voice to the community for such patches being applied. This would also allow non-contributors to post patches and then after going through the process one of the contributors could put the approved patch into the repository.
This would turn jME into a much more structured, but community-driven project I think. I'm just afraid adding a bunch of new people that have unrestricted commit access will thrust the project into a chaos of mismatched code.
Though it may be the end of this year before I'm doing any game development again, I am happy to help take on some responsibilities in the forum if that will help you guys out. I try to stay at least moderately active in the forum these days and am happy to moderate a bit more. I do like Irrisor's idea of community moderators though. That's a much safer task to delegate out.
This isn't a bad idea, as it would allow for users to submit to the repo themselves (taking burden off of us who no longer have the time), giving a lot of control back to the community, but at the same time restricting that access via a policy. So, if anyone subverts the policy (submit to tracking, reference track link in forum post, wait for comments, submit), they can be dealt with (losing write ability if need be).
I still think approving anyone to be a contributor is the way to go though, more as a symbol of the new "openness" than anything else.
I readily agree. The more we can push to "community approval" not only frees us up, but makes the community feel more empowered and ideally more likely to help out.
I think that's one of the struggles we've been dealing with is that the community feels it's only their job to find the bugs (not all of course, but the majority), not to help out in fixing the bugs. If we have a process in place that lets them submit patches it would allow them to feel more responsible for fixing things.
Also, perhaps we should add either karma or something as sort of a "benefit" to helping us out. So people that fix lots of bugs would be elevated (at least in the communities eyes) to a higher level. We can always hand out titles in SMF, but that would require effort on our part. The nice thing about karma is that it's community driven as well, so if someone submits a really awesome patch for community approval the people responding can also give karma points to them. I don't recall if this is a built-in feature of SMF that you have to turn on or an add-on.
Ok, I'll get this going this week. I'll have a few moments of down time this week to make the post and handle requests, etc. I'll also look into a SMF karma system as well.
mojomonk said:
I'll also look into a SMF karma system as well.
I've done that already and it seems 1. there's nothing appropriate for stable smf versions (only for the beta) and 2. does not really suite to improve community effects (imo).
irrisor said:
mojomonk said:
I'll also look into a SMF karma system as well.
I've done that already and it seems 1. there's nothing appropriate for stable smf versions (only for the beta) and 2. does not really suite to improve community effects (imo).
1.) Yes there is, it's a built-in feature of SMF (see: Admin -> Features and Options -> Karma)
2.) I very much disagree. As silly as I personally think it is, it can have a drastic effect on communities where support is needed. I think you'll find forums that use it have a much better community support since people are often competing to answer questions before another person just so they can have the karma.
darkfrog said:
1.) Yes there is, it's a built-in feature of SMF (see: Admin -> Features and Options -> Karma)
of course, but that's really crappy (this one is ok: Advanced Reputation System)
darkfrog said:
2.) I very much disagree. As silly as I personally think it is, it can have a drastic effect on communities where support is needed. I think you'll find forums that use it have a much better community support since people are often competing to answer questions before another person just so they can have the karma.
sometimes, yes. But it has negative effects as well :|
Why is it so crappy? Seems like Karma would be pretty simple…I'm curious what functionality it lacks or does poorly?
Well probably that advanced reputation system I linked is just more like I would expect a karma system - you can compare yourself. If you like it really simple smfs default is probably ok.
I don't especially care…if you like the other one more then I'm all for it, but the way you were talking they all suck. :o