[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-games-devel
Subject:    Re: [Kde-games-devel] Being admins of the git repos
From:       Ian Wadham <iandw.au () gmail ! com>
Date:       2012-10-06 0:22:17
Message-ID: 40657BD9-EC73-4309-B91B-4F28A4F2D8B3 () gmail ! com
[Download RAW message or body]


On 05/10/2012, at 10:26 PM, Roney Gomes wrote:

> On Sat, Sep 8, 2012 at 12:53 PM, Albert Astals Cid <aacid@kde.org> wrote:
>> The git repos have been already created, though some of them are still e=
mpty
>> waiting for Wolfgang's magic touch.
>> =

>> At the moment Wolfgang and me are admins of all the kdegames git repos, =
if you
>> wish to be admin (in projects.kde.org speak) of a given repo please answ=
er
>> this mail and tell me which repos you want to be admin of (I think the o=
nly
>> thing it gives you is power to delete branches and to some metadata: nam=
e,
>> description, etc in projects.kde.org)
> =

> I want to be the admin of KBounce and KNavalBattle. I worked a lot on
> them during GSoC and want to keep the job. What I don't know is
> whether it's a problem to be the maintainer of two games and whether
> is there any set of responsibilities or code of conduct that a
> maintainer have to follow. Is there any?

Being admin of git repositories and being maintainer of the contents are
two different things.

IIUC the admin of a repository just has access to a few more git commands o=
n it,
which might never need to be used.

Roney, I am pleased and proud (as your former mentor) that you would like t=
o be
maintainer of KBounce and KNavalBattle.  That means being around for a while
to fix bugs, consider wish list items or add any features you may fancy.  I=
f you
have an idea for a new feature, it is a good idea to let people on this lis=
t know,
to give them an opportunity to discuss it.

I do not think looking after those two games would be any problem for you.
The amount of work depends on the size and complexity of the code and
the frequency and backlog of reports on it on bugs.kde.org.

Re responsibilities, have a look at http://techbase.kde.org/Policies

The most important to read is the Commit Policy.  Although it was written f=
or
SVN, it would still apply to GIT, with a few minor changes.  Re Coding Styl=
e,
that is for *library* programs, but it is good for applications to follow i=
t too.

You need to be aware of the release schedule and feature plans, currently
for KDE 4.10, see:

http://techbase.kde.org/Schedules and an example at
http://techbase.kde.org/Schedules/KDE4/4.10_Feature_Plan#kdegames

If you have new features to introduce, you need to do the work before the
Hard Feature Freeze and give notice of it well before, on the Feature Plan.
Also, watch out for the Message and Documentation freezes, needed to
give translators time to translate UI, message and handbook changes.

Last but not least, we keep a list of maintainers at:

http://community.kde.org/KDE_Games/Maintainers

Please update it for KBounce and KNavalBattle.  Normally we would write
to the previous maintainers to get their OK, but we have not heard from them
in quite a while and you already did a lot of changes during GSoC, so you
are effectively the maintainer already =85 :-)

Welcome to the club!

All the best, Ian W.









_______________________________________________
kde-games-devel mailing list
kde-games-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel
[prev in list] [next in list] [prev in thread] [next in thread]