Revision as of 17:45, 27 April 2012

Packaging Recommendations

Prior to the BoF a few people had been talking to the distro packagers about the way they go about packaging KDE and KDE Games. It seems it s becoming more common to package each game into a different RPM/deb/whatever and then to provide meta-packages which will include a number of these. There is also the issue that for a default desktop installation a distro will choose only a small number of games (4, say). We, as a project, want to make the packager's job as easy as possible and so we came up with the idea of categorising our games into a number of 'packages'. These packages are logical groupings of games so that without having to review all the games themselves, the packagers can easily now which games are well suited to a default installation, which would be appropriate as desktop games etc. And so the categories we came up with were as follows:

Minimal

This group will contain only the very minimal games that any user would expect to have on their desktop. This means, e.g., KMines, KPat, KMahjongg etc. This should probaby not contain more than about 5 games.

Extended

This group will be all the high quality games which we would expect to have a large user base. e.g. games like KSudoku, KBattleShip, KBreakout etc. Those games which are quite specific to a certain user base or which would not qualify as casual desktop games

Extra

These would be the games in extra gear which we consider to be useful additions to the distro.

Friends

This would simply be a mention of those 'games' outside kdegames which we consider to be games. This would be things like StepGame, Blinken etc.

These categorisations would not be reflected in the structure in SVN, they would merely be recommendation to the packagers.

The groups would be compiled in a list in a file called README.PACKAGERS in kdegames root. This list has not yet been created and we will likely need a bit of discussion to decide which games should go where.

Action needed

Create the list and decide which games should be in which category (all KDE Games members)
Create the README.PACKAGERS file

Bugs Mailing List

It was suggested that in order for all KDE Games members to keep track of the areas of KDE Games that need help (outside of their own game) that we should create a mailing list to which all new bugs (and perhaps bug edits) should be CC'd.

The mailing list will likely be called something like [email protected]. Once it is set up, I will let everyone know.

Action needed

Request the new mailinglist and ensure all bugs are CC'd to it. (Matt Williams)

Bug Fixing/Triaging Days

We thought about organising a KDE Games bug fixing and triaging day like what the Bug Squad do each week. It would make sense to contact them to see if they could help out with this. It would involve going through all the bugs in the bug tracker and removing those which refer to old games, closing those which are fixed, requesting more information on those that are not and fixing those which we can.

Should wait at least until the new mailing list is set up.

New Developer Mentoring

Dealing with new developers was discussed and we decided that given KDE Games' excellent position as one of the main modules that people can most easily get involved with we should do more to make it easier for people to get into the KDE spirit/community. We're going to try to organise ourselves a bit more to create a specified point of contact or two who will be there to guide new developers through the process of creating and submitting patches, finding bugs for them to fix in order to introduce them to the KDE Games code base and getting involved in our community.

For this I will create a page on Techbase where we can collate who the contacts are as well as useful resources for new developers.

Action needed

Create Techbase page and find people willing to be official mentors (Matt Williams)

New Game Criteria Checklist

This concerns the rules for allowing new games to enter the kdegames module and for allowing a game to pass into a release. The current process of going through kdereview works well and the requirements for that (documentation, i18n etc.) all still apply to games but we would like to introduce a number of further criteria for new games to ensure they of a high enough quality. We want to make these criteria explicit so that developers creating a new game can check against the list so that they know what is expected of them. This list will consist of things like theming, using kdegameslibs classes where appropriate, GHNS etc.

The list will be available on Techbase.

Action needed

Create list of criteria (all KDE Games members)
Create page (Matt Williams)

Rules for Unmaintained Games

As a release approaches we will need to make sure all games in the module are tested to ensure they meet the release-ready criteria which coincides with the new game criteria above. We will need to make sure that all games are actively maintained and have no large unfixed bugs.

We will be taking a stronger approach to games which have unfixed bugs with no maintainer. In this case we will move the game back to playground.

In the case that there is a maintainer but they are too busy to fix the bugs or add essential new features, the game will be moved to extragear where they are not bound by the kdegames release schedule so they can work on fixing the bugs and adding the features in their own time.

However, given all this, we'd like to see KDE Games as a community taking a certain amount of responsibility for the games in our module. That means making an effort to fix bug in games that are not yours, especially if that game is in danger of being removed. The new bugs mailing list will help us with this.

Action needed

Full testing of all games before a release (all KDE Games members)
Take care of all games, not just your own (all KDE Games members)
Be strict when it comes to buggy/unmaintained games (Matt Williams)
Organise people to be testers to make sure we have full coverage (all KDE Games members)

Usability

It was discussed that the biggest usability problem that we face is a lack of consistency betwen games. This is in both the visual UI and the workflow of playing a game. A certain amount of this can be standardised be putting stuff in libkdegames and encouraging games to use it (see game criteria checklist above).

Once we have polished the games as much as we can (or maybe before), we plan on working with the wonderful usability people to help us make our games better.

Action needed

Create a Project User Research Template for KDE Games as a whole as well as for a number of individual games. See Projects/Usability/Project_User_Research_Template for more info (all KDE Games members)
Decide on standards for certain things. e.g. how to start a new game (all KDE Games members)

Accessibility

We need to think about making our games more accessible. For the most part this means considering making your games playable entirely through the keyboard. It was decided that we would not make this a project priority since we have other things to work on and we have very little knowledge about what is really needed to make a game accessible.

Action needed

None for now unless someone is an accessibility expert

KDE Games Developer Meeting

A few of us talked about having a developer meeting sometime in the next year. This is a meeting where we all go somewhere to meet in person for a few days and discuss and hack on KDE Games. This idea is still in a very early stage but it is worth discussing possible locations and times.

The thought has just occurred to me that it might even be worth synchronising this with a kdeedu meeting since our two projects have a lot to offer each other.

Action needed

Discuss (all KDE Games members)

kdegameslibs Module

Vladimir and Aliona presented Step and StepGame and the problem of the more game-like applications in kdeedu not wanting to depend on kdegames as a whole. It was decided that the best solution was to create a new module (on the same level as kdelibs, kdegames, kdepimlibs etc.) called kdegameslibs which would contain any common libraries needed by kdegames and kdeedu. This would not involve moving all of the current internal libkdegames into the new module, only the stable (ABI, API), maintained and essential parts would be moved.

It has not yet been decided exactly what would be moved across but it would likely include the theming stuff, my (currently non-existent) new highscore stuff, popup item and similar. I would be the module maintainer and release manager.

Action needed

Talk to release-team about creating the new module (Matt Williams)
Decide on the part that should be moved in (all KDE Games members, particularly those who are maintaining a part of the current libkdegames)