More Community-driven Development

[Cornstalks]

Currently, Laurent is pretty much the only SFML developer (with Marco doing OS X stuff). This is nice because there's a good level of consistency and sanity maintained in the codebase. However, we also only get a handful of commits each month, meaning things move quite slowly.

I've worked a little bit on other open source projects, like FFmpeg, and while FFmpeg has a much greater learning curve, I feel like it's easier to contribute to it. There are a number of people who have said "X would be a good idea/feature" and Laurent will say "Yeah, but it will require a decent amount of changes to SFML so don't do it; I will do it to make sure it's designed like I want it to be," which means users end up waiting on Laurent rather than being able to contribute.

This isn't necessarily a bad thing, as I've said, as it helps with a consistent and clean API in SFML, but I feel like SFML could really benefit from more community contributions and I'm wondering how that can be stimulated while still keeping full control in Laurent's hands.

There are, of course, a list of bugs the community can work on fixing (and hopefully I'll get to contribute to this during this summer), but there are other features that I know people are itching to have (like Android/iOS and OpenGL|ES 2.0 support) or other road blockers (like documentation/web stuff for the 2.0 release) that I think people would love to contribute to.

What would help encourage the community to contribute? Here are some of my thoughts, and I'm hoping others can contribute ideas/suggestions/comments:

More road maps or architecturing. Particularly, for things where Laurent says "Don't work on this, I'll do it so I make sure it's done how I want it," what if instead a skeleton/architecture was designed so that either Laurent can fill in the skeleton/architecture himself or someone else can implement it and send a pull request. That way the API and design will stay how Laurent envisions it, but eager users can contribute instead of wait.

A web page for contributing. There's some instructions at the end of SFML's README, but they're quite minimal and nowhere on the website. I think if there was a "Contribute" tab on the website that talks about contributing and helps users get involved in contributing to SFML, that would help.

Prioritized issues. If I want to contribute to something, I'd like to know what you'd like me to contribute to. Sure, contributing to any issue is nice, but prioritizing issues (maybe with tags) will give people a sense of what needs contributing the most.

Mini intro to working with github (and pull requests). I'm more familiar with the mailing-list style patch submission and review, like is done with FFmpeg. I just spent the past while poking around github trying to figure out how pull requests work and if I submitted a patch, how it would be reviewed and (if needed) updated/fixed. I think I understand how it works now, but if the entry barrier can be minimized as much as possible I think people will be more inclined to contribute.

Any other ideas, or any responses to these ideas?

[Laurent]

Good idea. I'll let the discussion grow before answering

However, we also only get a handful of commits each month, meaning things move quite slowly.

Keep in mind that since the RC (approximately 1 year ago), I mostly worked on the documentation, tutorials and website. So the lack of commits doesn't mean that things progress slowly, just that there's not just code

[Jebbs]

I think this is a fantastic idea. Not only could it lead to getting SFML features/bugs taken care of faster, but an active community will help bring in more users. And I'm sure various people would be able to contribute more than just code work. For example:

I mostly worked on the documentation, tutorials and website.

There are many intelligent and experienced SFML users (ie, not me) who could work on things like tutorials and possibly documentation. Hell, eXpl0it3r writes example code and explains things to people all the time. Being able to delegate certain tasks like these to people would give you (Laurent) more time for those important fixes and features instead of eating up all that time.

[Sui]

The skeleton suggestion is a good one. Laurent can maintain architect status and other coders can be allocated to fill in the meat of the code (sticking with the skeleton metaphor). Before I read the post in full, my first thought was Laurent controlling interfaces.

Laurent has done a brilliant job with SFML but functionally SFML is being left behind by other libraries/tools like Mono Game, Unity and Monkey. I appreciate these have commercial licenses for mobile tech.

Microsoft's Direct-X only on Metro (Windows 8 touch) apps decision means Direct-X code will need to be integrated into SFML to support Windows 8 fully. This is almost a rewrite of SFML (interfaces aside).

I would like to contribute if/when something is set up. Need to find a way to manage my time... discussion of that topic is for another thread!

[Tank]

Maybe some words from the SFGUI front may help.. I'm aware that SFGUI is not as widely spreaded as SFML, but we are already far beyond the 1,000 downloads mark and also received quite some contributions in form of patches -- also *after* we moved away from GitHub, which made it even harder for people not being familiar with Git in multi-user environments.

1) We tell contributors to discuss new features with us on the forum/IRC before starting work on something. The reason is that we have a roadmap in mind, and we want SFGUI to follow a specific route. We don't want people to send in patches which don't get accepted because we planned something differently.

2) We gently ask contributors to follow our guidelines, which have been written down in a textfile. You can't cover everything, that's for sure, but most contributors follow them. If there's something wrong, you can ask the contributor to adjust the patch, so that you can accept it (important: Tell them that it's already *accepted*, it just needs some adjustments!).

3) Be actually open for contributions: If someone is willing to work on something and you're fine with the feature, let them do it. Give them information for guidelines, requirements etc., and when they're done, discuss the patch or just accept it.

4) You're not giving away control, you're giving people the opportunity to work *for* the project. I can often feel Laurent's fear of losing control of SFML. But that's really unfounded. What makes its way into the master tree is completely up to the maintainer. It's like the Linux kernel: Hundreds of people are writing code, and through a hierarchy of trust and control mechanisms, patches make their way up to Linus, the last point of control.

5) Be more verbose with your own plans, roadmaps and ideas. Use public services to manage your todos and progress, like the GitHub tracker. This is mainly important for coordinating work and for other people being able to see what's happening at the moment and where they can jump in (basically what Cornstalks said; he has some strong points IMHO).

6) It's fun!

[eXpl0it3r]

I quite agree with Cornstalks and it has been bugging me for a while now.

It would be really nice if we as a community get more information on the current development status and the future plans and also get the chance to contribute to things like website development.

There are many intelligent and experienced SFML users (ie, not me) who could work on things like tutorials and possibly documentation. Hell, eXpl0it3r writes example code and explains things to people all the time. Being able to delegate certain tasks like these to people would give you (Laurent) more time for those important fixes and features instead of eating up all that time.

I'd gladly help writing tutorials or similar things, but as Laurent said many times in the past, it's something he feels has such a high importance, that he wants to do it on his own.
I can kind of understand that, but in return would also expect that things get done within an 'usual' time frame. Life can be quite hard, with a family, a full time job and all the other surrounding stuff, but working on some simple tutorials for over half a year, which automatically lowers the work on the actual code, is not very usual to me. That's just my opinion - I'm long over this issue and don't really mind the delay anymore.

Microsoft's Direct-X only on Metro (Windows 8 touch) apps decision means Direct-X code will need to be integrated into SFML to support Windows 8 fully. This is almost a rewrite of SFML (interfaces aside).

I'd say it would be way easier to connect the OpenGL backend with something like ANGLE, which again would need a port to OpenGL ES...

[Foaly]

I have to agree with the other people. I think it's a great idea, if other developers where able to contribute to the SFML. It has also been bugging me, that the development of the library has been basically stopped for almost a year now. With development I mean addition of new features. Of course there have been a lot of (awesome) bugfixes (like the intel rendertexture bug for example) which is what the RC phase is for. But I think it would be better if the other developers would be able to see a more detailed roadmap and help out and contribute that way.
I also agree with the others, that if a discussion shows, that a feature should be added to the library, Laurent should have the final say on the design, but other people can contribute patches. If they are not up to Laurent's standarts, design or guidelines, he can send them back with a note on what to change. (like the skeleton metaphor or the linux kernel)

edit: prioritizing issues is also a good idea. That way people can see how quick they can expect a bug to be fixed or a feature to be added. It also helps to distinguished between major and minor features.

[Cornstalks]

Good idea. I'll let the discussion grow before answering

I'm not sure this discussion is going to grow much more (though if more people have input that would be awesome!)

[cloudncali]

There are, of course, a list of bugs the community can work on fixing (and hopefully I'll get to contribute to this during this summer), but there are other features that I know people are itching to have (like Android/iOS and OpenGL|ES 2.0 support) or other road blockers (like documentation/web stuff for the 2.0 release) that I think people would love to contribute to.

I am one of those people

I really like this idea and would love to help in any way I can, Though life and helping with GQE keeps me pretty busy I would love to help where I can.

[MorleyDev]

To play devil's advocate: A problem I see is that whilst a team that works closely together and plans together can maintain consistent coding standards, it's a lot trickier to do that the more separated a team is.

Bug fixes are one thing, but adding whole new feature sets would be something differently entirely. And by setting up a skeleton road map, you runs the risk of being *too* strict. Running too close to the dreaded "Big design up front".

And then when the code smells appear that signal the need to refactor, there's a danger the refactoring may need "permission" to be carried out because of the areas it touches. Which, given the programmer nature to follow the path of least resistance, may result in the resistance of seeking that permission becoming dissuading them from doing the refactoring. And if that happens, DRY principle becomes a distant fairytale.

It's a risk that'd need managing, though one a lot of open source projects probably have to manage. Not all succeed, with code that can be described as a complete and total mess. But not all fail either, managing to keep a very neat architecture that grows smoothly and easily, and stays easy to use.

[Laurent]

I'm not sure this discussion is going to grow much more

Yep.

So... I agree that involving more contributors can't be bad for SFML. Right now I'm busy finishing everything for SFML 2, but once it's done, I can think about what you suggested. I think that the 4 points that you mentioned can be a good start

[Nexus]

I wonder whether GitHub pull requests are a good way for community contributions. They don't make it easy to adapt commits before merging them. But adaptions from the repository owner are almost always necessary (code style, commit message, ...), making the web-interface button "Merge this pull request" close to useless. And creating a separate branch for each request can also over-complicate things, if a single commit containing the changes would be enough.

How do you usually handle user contributions?

[Laurent]

I find pull requests very useful. First, it makes integration super easy: it's just one click for me. And since I never have much time, it can make the difference between something that is integrated and something that is not.

The Git environment is also perfect for this kind of contribution: you can (very easily) fork SFML, work locally on your own version, rearrange commits if needed, etc. and only when everything is ready for integration, you submit it.

But adaptions from the repository owner are almost always necessary (code style, commit message, ...), making the web-interface button "Merge this pull request" close to useless

This is not a relevant argument, because (at least for now) I don't integrate something before it is 100% ready. I prefer discussing with the contributor, making him do a lot of modifications to its code if needed, but at least:
- he has the time to do it
- I can then merge its code with one click
- he learns my coding style, making future contributions from him easier

I'm not a big fan of patches, but that would be my second choice. One can clone the repository, work on it, and then export all his modifications to one or more patch files, that I can then apply quite easily. I don't know if the corresponding commits will be marked as being from him or from me, though.

Of course, we're talking about important contributions. If there are only a few lines of code to change then posting them on the forum or sending them by e-mail is fine.

[Nexus]

I have to express myself more clearly: I don't question the usefulness of pull requests in general, but the way they are implemented on GitHub with the merge button. If the feature or bug fix contained in a pull request is considered useful, there are often just tiny details that prevent one from directly merging it: Indentation of constructor initializers list, a comment that I myself would formulate differently, etc. Telling all of these points to the pull requester takes a lot more time than simply fixing them. In addition, the GitHub uses a constant tab with of 8 spaces, which makes it necessary to view code in my own IDE to see if things look properly (I know you don't have this issue with SFML).

In short, discussing with the pull requester until everything is 100% correct for a direct merge to master doesn't look like an optimal solution to me. After the major things are fixed, I would probably rather create a branch based on the pull request, which I edit locally until everything is fine, and then merge this branch to master in a single commit. But I'm not sure how the usual approach here looks like, I haven't worked with pull requests a lot.

Also, I think every bigger change should be discussed on the forum, because the comments on GitHub are very limited and questionable (one can simply edit or remove own posts without annotations).

[Haze]

Telling all of these points to the pull requester takes a lot more time than simply fixing them.

I find this part questionable, because it seems to me we're talking about:
- dropping a comment on github
VS
- merge the pull request,  open your development environment, make the changes yourself and commit them.

If the contributor needs to apply a couple of another commits to his pull request before Laurent can approve it, of course it will take longer for the pull request to find its way to the upstream repository, but it will probably save Laurent's time overall.