Libre Software People's Front

don't confuse it with People's Front of Open Source

Posts Tagged ‘mswl-manage

Use the imperative, Luke

leave a comment »

When you commit changes on a repository that fix a bug, what do you put in the message log?:

  • Fixed bug (adjetive)
  • Fixes bug (3rd person, the commit fixes the bug)
  • Fix bug (imperative)

For me it is logic to use the 2nd approach which details what the commit modifies but according to the de facto standard the most recommended form is the 3rd one. The Git documentation to submit patches suggest that the body should provide a meaningful commit message, which uses the imperative, present tense: “change”, not “changed” or “changes”. Tim Pope explains this in his blog saying that this convention matches up with commit messages generated by commands like git merge and git revert.

Next time you do a commit, remember to be imperative as if you were the Master of Puppets Commits 😛

Advertisements

Written by sanacl

March 1, 2011 at 12:11 am

Posted in Uncategorized

Tagged with , , ,

The KDE Community Working Group

leave a comment »

A few weeks ago Adriaan De Groot (Vice President of the KDE Foundation Board) explained us in the master on libre software the different issues that are important to be taken into account in order to maintain a big community such as KDE, where there are people working together from different countries, with different timezones, culture, languages, … Looking after the KDE community is maybe the main goal of the KDE e.V. non-profit organization which was created with the aim of offering representation, support and governance to the KDE community.

Inside the KDE e.V. there are three working groups: Community, Marketing and System Administration and I was curious about the first one. KDE people are not different from the rest of human beings and sometimes they end up with problems that need a special action, these kind of issues are handled by the Community Working Group which is only three years old and it’s composed of 5 people.

This is part of the formal definition:

“The Community Working Group aims to act as a central point of contact by being available to communicate user needs and concerns to developers, and developer intentions and plans to users.
The group also acts as mediator upon request in the rare cases where the communication breaks down. If these are issues regarding expectations, the work will be closely coordinated with the Marketing Working Group.”

The CWG bases on the KDE Code of Conduct an important part of its job, this document details the social norms and expectations for the community members. The CWG members act as mediators when someone feels that the Code of Conduct has being violated, then they try to resolve the problem amicably. Sometimes this is not possible, in those extreme cases the CWG will suggest to the e.V. Board the most helpful action for the KDE community. The CWG does not, itself, take any action.

References:

Written by sanacl

February 15, 2011 at 10:04 am

Interview of Stefano Zacchiroli in the OWF2010

leave a comment »

Written by sanacl

February 6, 2011 at 11:51 am

cp Redmine Chiliproject; chmod g+w Chiliproject

with one comment

A couple of days ago some people from the Redmine community announced the creation of a fork, its name is Chiliproject. For those of you that don’t know Redmine, it is a libre software project management very popular during the last two years.

Redmine is an active project, the creation of a fork could take away contributors from it and the forked project will have a strong and popular competitor, the reasons to create a fork in those cases must be very strong. The Chiliproject leaders explain it in a post, they basically complain about the community management which from their point of view have to be more open.

… Integration of community-created patches were too sporadic, lacked a clear methodology, and was interfering with the effectiveness of the Redmine project for its users. Over the past two years, several members of Redmine’s community worked to resolve management bottlenecks through clear suggestions and contributions. They also attempted to broaden and open up the development process to more contributors. But efforts via public and private forums to discuss the goals and future direction with the project manager of Redmine failed, as the current project manager did not share these priorities

These are the reasons why some people from the Redmine community decided to create a new project, they want to put in practice a more transparent and open governance model following the “ideals of Free and Open Source Software ethics, governance and development practices”. During the following months we will witness a very hard competition where two similar projects will use two different approaches to manage its community. Will Chiliproject be able to attract more code contributors than Redmine? Won’t Redmine lose a bigger part of the community in favour of Chiliproject? These questions will have an answer by the end of the year.

References:

Written by sanacl

February 5, 2011 at 9:00 pm