[Kdenlive-devel] Workflow for new (and current) contributors

[Simon A. Eugster]

Hey jb,

On 11/09/2011 04:16 PM, jb wrote:
> Hi.
>
> The move to git and KDE servers is now functional, and I think we need to
> agree on how we integrate new developers, and what are the rules to join /
> contribute to Kdenlive.
>
> First, developers need to understand and comply to the git workflow (which
> branch should be used for what, ...), Alberto will probably write something
> about it in the next days.
>
>
> 1) Getting a developer account
>
> I am not very sure about that, but my first idea was to make it rather easy to
> get a developer account, maybe request a quick presentation on the mailing
> list unless the contributor is already known in one way or another.
>
> New developers get developer access on the git repo and a developer access on
> the Mantis bug tracker.
>
> If that is not working, we can change it to a more formal way: send x patches
> before getting access... but my previous experience on KDE's repository where
> a lot of people had write access was rather positive.

I agree to be rather liberal there. But, isn't it that way that KDE has 
to agree as well since a dev has access to all KDE repositories? (If I 
got this right.)

> 2) Contribution and collaboration

agreed

Simon

> How about that:
>
> When someone wants to work on a bug or a feature, the process is:
>
>   - Assign a mantis issue to yourself (create a new ticket if bug or feature
> does not yet exist in mantis). That way, we can keep an eye on who's doing
> what in the project.
>
>   - If the feature involves important changes to Kdenlive or can change the way
> users work with Kdenlive, post a mail on the devel mailing list so that we can
> discuss about the implementation and consequences.
>
>   - Work in your branch and request comments / review if you are unsure about
> your work
>
>   - Merge to next for review / testing
>
>   - When one of the project maintainer says it's ok, merge to head.
>
> Of course, this is not required for normal / simple bug fixing which can be
> committed to master.
>
> If a developer does not follow the rules and repeatedly breaks the code or
> introduces too much bugs, we revoke his git developer access and request him
> to send patches for his contributions.
>
> New contributors can also send patches to the mailing list, and we are also
> looking at KDE's reviewbord system which allows to send patches.
>
> When we agree on something, I will set up a web page explaining how to
> contribute / join Kdenlive, so your comments are welcome.
>
> regards
> jb