Abilities of GTG developers
GTG developers are members of the GTG launchpad groups. It involves :
- commit access to the trunk and any gtg owned branch
- full administration status to the bugs database (assigning, targetting, changing status)
- administration of the whole GTG launchpad page (including translations and groups)
- ability to make releases
access to the dev-only mailing list (you have to explicitly subscribe, it's not automatic)
- fame, glory, money and tons of naked men/women wanting to spend the afternoon with you in a Jacuzzi
GTG developers can also request (on the dev only list) :
It is recommended to GTG developers to subscribe to :
Bugs change in the GTG project : https://edge.launchpad.net/gtg/+subscribe
Revisions changes in the Trunk : https://code.edge.launchpad.net/~gtg/gtg/trunk
Previously, the GTG dev group was subscribed but it's not mandatory anymore.
Becoming a GTG developer
You are contributing more and more to GTG and you think that having commit access to the trunk or any ability listed above would be helpful for your contribution ? Then find one of the gtg developers and ask them.
Of course, we have to know you and trust you for your contribution. If you contribute code, we should have confidence that you are now a gtg master and that you've fully understood our coding rules. It usually means that your latest patches were all merged without any need to resubmit them.
Also, it has to make sense. Some GTG heavy contributors are not GTG developer because it would not help them and because they work on their own branch anyway.
Responsibilities of a GTG developer
The fact that you have all the abilities listed above doesn't mean that you should use them. When in doubt, ask ! It only means that we trust your judgement so you know what you can do without risk and what you should ask advice for. If you are part of GTG dev as a webmaster, it means that you will probably not commit code. If you are a plugin developer, it's convenient for you to have access to the trunk so you can maintain your plugins but if you want to commit to a previously unknown part of code, submit a patch.
As a rule of thumb, any change to the UI behaviour or to the internal API should be agreed in a bug or on the list.
When marking a bug as "fix committed", you have to assign that bug to the next release. When this release come out, we will mark them all as definitely closed. If an unexpected intermediate release happens, we simply re-assign all the fix committed to this new release.
Being a GTG developer also means that bug can be assigned to you because the others are too lazy… hem… feel that you are the best for this task !