SVN Commit Access Guidelines

General Discussion Community Planning
1

Ill start this off with a discussion on how we think we should give svn access to the community.

A few thoughts on my mind:

Copyright/ownership: Jive had people sign a form giving ownership of the contributed code to them, essentially. This made sense for splitting the license between commercial and GPL, but that has gone away now. But the idea is still useful; look at the Linux kernel for an example. With so many contributors, they couldn’t change from GPLv2 to GPLv3 if they wanted to (they cant get the consent of all the owners) How are other projects handling this? How do we want to handle this? Im pretty sure that as of today all users with access have signed such an agreement with Jive Software, so we at least have a clear starting point. Does Jive still want legal ownership over the code? Or with this move is that changing?

Vetting: I dont like the idea of giving access to any random person with a patch to apply. Debian created a community of developers that handles this well most of the time (it has its share of kinks too). The idea is to become a developer, you must first be “mentored” by an existing developer until you meet certain requirements. I personally feel that Debian’s idea is good, but their current implementation is too clumbersome for new developers. Since we are a smaller group, we can make the rules a little easier. My first thought was

  1. Get assigned a mentor
  2. Submit patches to the mentor that close N issues (where N = 2-5??)
  3. Mentor (and others) review patches, make commits on behalf of dev-in-training
    After those steps are complete, (and the above ownership issues addressed) svn commit access is granted. I dont think its good to open up svn access to just anyone, but the bar needs to be lowered a little.

It might also be worth looking into using ACL’s in the svn trees- For example; after getting svn access, you only get access to trunk. You need to be vetted further (elected? appointed?) to put changes into tagged releases/branches/etc. Ive not used svn acls before, so I dont know how hard that would be to manage.

I think all people with svn commit access should be indicated in some way in the forums. Maybe this is what the KeyContributor badge is for. Can a person have more than one badge in the forums? Like having badges for dev-in-training, developer, issue-reporter, etc

2

Re: badges… only one badge can be displayed at a time. However, we could have different versions of the “key contributor” badge to distinguish the different levels. Also, (per an IM conversation slushpupie and I are having) we could maybe use the OrgChart functionality to help track that.

Re: svn vetting and access, it all sounds good to me.

3

slushpupie wrote:

How do we want to handle this? Im pretty sure that as of today all users with access have signed such an agreement with Jive Software, so we at least have a clear starting point. Does Jive still want legal ownership over the code? Or with this move is that changing?

I think it’s a very important practice that code be submitted via Contributor Agreement. It protects the integrity of the Open Source project. We (Jive) would be open to the contributor agreement being signed with a different legal entitiy. However, there may be some good reasons to delay that for a bit:

  1. Someone would need to go to the trouble of creating a new legal entitiy. It’s probably a lot of work and moderate expense.

  2. Jive is prepared to defend the Open Source code base from a legal perspective while we’re still the ones the Contributor Agreement is being given to. I’d like to see the community mature considerably before it has to take on that burden.

4

Each meaningful svn commit needs to be against a Jira ticket. Can this requirement be enforced with a svn commit hook?

5

Yes, we could add a hook that matches our list of JIRA projects.

6

Good idea. I dont know if it can be programatically enforced (Im sure it can) but policy should. Perhaps you get 3 strikes against the policy before your access is revoked? To go with this, I think its also important that when a bug is fixed in trunk, that its marked as completed, but not closed. It shouldn’t get closed until verified by the reporter or some other person (not the developer).

7

I think adding an SVN hook to force a JIRA tag to be in the issue is a bad idea. We should not do this.

Don’t get me wrong, I agree that it is good practise to add JIRA tags in subversion commit comments where appropiate, but I’m opposed to enforcing this.

Rules that are enforces are limiting people, either in the way the rule was intended, or in another way.

If someone is going to be limited by this rule in the way that the rule was intended (in other words: is someone was lazy and didn’t create or lookup a JIRA issue number), there’s not a big chance that this rule would lead to better behavior. Instead, people will find easy workarounds. These workarounds would add malformed or plain false information to the commit message, which in my opinion is worse than having no information at all.

On the other hand, not every commit message needs a JIRA issue. I regularly commit, for instance, small code maintenance revisions: “added javadoc” or “fixed import”, “removed stale variable”, stuff like that. These commits don’t need a JIRA issue. SVN hooks that would make it more difficult (annoying) to commit small improvements like these. Therefor, they are likely to cause less of these improvements to be committed.

As I said, I’m (strongly) against adding such a hook. The amount of committers is not that big - it shouldn’t be hard to agree to a small set of “good practise” guidelines, which we all agree to respect. After all, we’re all somewhat responsible individuals, right?

Furthermore, I’m not seeing the problem that we’re going to solve with a rule like this (I don’t think that things are going badly wrong now). With this in mind, adding restrictions to force people to do something that they’re already doing is counter-productive: it will at best annoy people when they choose (for good reasons) not to include a JIRA issue number.

Lastly, the proposed mentoring system would add a nice mechanism of teaching/convincing new committers of the value of these guidelines. I would leave it at that.

8

I generally agree with the idea about mentors and agreements signing. Who will be these mentors? Assuming Daryl, Slush, Guus? Maybe Matt, Gato also? In this area i’m not really skilled, i’m not a programmer, so i’m not proposing myself. Though, i have setup a testing environment, i can sync SVN, apply patches and test. If the patch is simple (GUI, some trivial change) and i can test it, i can commit, but i won’t see any potential errors in the code, so i can brake something. So, maybe i’ll stay at the JIRA and the forums.

Guus, what about gathering a number of such small changes to a single ticket? Though, i agree that this policy can be optional and in such cases there can be no ticket for such changes.

BTW, Guus, i have tried Nimbuzz on my phone, with MSN. Nice app

9

Hey Wroot,

Sure, you could combine several trivial modifications into one JIRA ticket, but what’s the point? What problem would this solve? For these trivial tasks, JIRA tickets are overhead. Keep in mind that subversion is a modification tracking mechanism in itself - there’s no need for everything to be documented in JIRA (that would just clog up JIRA, and divert attention from those JIRA issues that are actually meaningful).

Thanks for your nice comment on Nimbuzz. Although I’m not working for them any longer, I’m still incredibly proud of what we’ve put together there.

10

Hi Guus,

I agree what with you are saying and don’t want to burden developers with tedium. I am definetely not a mentor, just know enough java to be dangerous.

daryl

11

Furthermore, I’m not seeing the problem that we’re going to solve with a rule like this (I don’t think that things are going badly wrong now). With this in mind, adding restrictions to force people to do something that they’re already doing is counter-productive: it will at best annoy people when they choose (for good reasons) not to include a JIRA issue number.

The problem here is bug tracking. We have two issues: Issues not getting closed, and fixed issues not getting reported. For the first issue, this enforcement is something that keep bug (and enhancements) tracked better. There are currently a TON of issues that have had no progress reported, but in some (many) cases some change has happened. For the former, its useful to track things in a way to know what all the svn commits go to.

Im not opposed to leaving things as a policy, and not an technological enforcement- but I think a documented and published policy of svn commit expectations is needed.

12

I generally agree with the idea about mentors and agreements signing. Who will be these mentors? Assuming Daryl, Slush, Guus? Maybe Matt, Gato also? In this area i’m not really skilled, i’m not a programmer, so i’m not proposing myself. Though, i have setup a testing environment, i can sync SVN, apply patches and test. If the patch is simple (GUI, some trivial change) and i can test it, i can commit, but i won’t see any potential errors in the code, so i can brake something. So, maybe i’ll stay at the JIRA and the forums.

To start with, it will likely be a small group like you listed. The hope is to grow the size over time, though. If the “mentoring” program works well enough, it can spill into the Google SoC or other programs like it.

13

I like the idea of a structured way of accepting new developers, enabling them to make direct changes to the code. I’m also in favor of making this ability publicly visible to others (through the forum interface, iow badges, labels, something like that). I feel that this would fill a gap that currently exists where community members don’t really know who to talk to to get something fixed. Being able to address someone directly “feels better” than adding a posting to a forum thread somewhere, hoping that someone will act on it.

That said, I’m a strong believer that software development is not a democracy. I feel that there should always be a small group of people (1 to 3 persons) that can have final say in anything related to the development.

We should avoid creating a group structure where no decision get made, because we constantly fail to reach consensus.

I’m not saying that every change should be OK’d by these people before it can be applied. I’d be in favor of giving commiters a lot of freedom to do whatever they feel is right. I feel that once someone obtains the status of ‘commiter’, this expresses a significant level of trust that’s put in this person. But, when push comes to shove, there should be a very small group of people that can override everyone and everything.

Basically, we already have such a situation: Matt and Gato are in this respect or fearless leaders. Let’s keep a setup like this.

14

Guus wrote:

I’m also in favor of making this ability publicly visible to others (through the forum interface, iow badges, labels, something like that). I feel that this would fill a gap that currently exists where community members don’t really know who to talk to to get something fixed. Being able to address someone directly “feels better” than adding a posting to a forum thread somewhere, hoping that someone will act on it.

Well. Badges are ok. But that can be a source of “spam” for these selected users. Even now with only a badge of KeyContributor i get a number of requests that are not bug reports. Forum users can abuse such users if we instruct them to submit directly what they think are bugs. I think reporting through the forums should stay, maybe with some improvements. Maybe a small group can have some specific tag reserved (“bug_report”), so then a member of this group can mark any thread with this tag, so others will notice it, especially if they a watching this tag.

Once there was an idea to make such bug reports threads distiguishable from other discussions and questions (a bug icon ?). Well, all of these changes depend on Jive and SBS.

15

Sounds good. I like these suggestsion. I do suggest we limit our efforts in ‘improving SBS’ to work with bug reports to some extend: let’s keep JIRA as the primary bug reporting tool, with SBS being a fallback for non-dev kind of people. Can we somehow making it easier for community users to report issues in JIRA?

16

That said, I’m a strong believer that software development is not a democracy. I feel that there should always be a small group of people (1 to 3 persons) that can have final say in anything related to the development.

We should avoid creating a group structure where no decision get made, because we constantly fail to reach consensus.

Yep, I think that’s the right approach. The small group can also be slightly different for each project – i.e. Smack different than Openfire.

-Matt

17

So, what about creating this Guidelines doc? Anyone willing to start? I think it should be done by someone with better English But if noone is willing, i can make a draft.

Also. Doc is not ready, but Jira admin access is already assigned and some other people are gaining the rights they need. So maybe we can do this with SVN also. I know Guus needs SVN (as he has lost hiss old credentials). I know that Guenther is updating the “Openfire patches waiting for trunk” document with his patches. Though maybe this document will became obsolete with the current approach. And maybe patches can already beeing added to trunk instead of adding them to this document.

18

Ill take a stab at it. Things are a bit crazy today and tomorrow, so it may not be until next week before I get it done. If anyone else want to give it a shot before then, have at it!

19

Initial documents just posted: Becoming a Contributing Member Mentorship Program

Please give feedback!

20

I think it looks good. Do you have time and motivation to push the process and be a mentor for me?