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 ;)
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.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.
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 (https://code.google.com/p/angleproject/), which again would need a port to OpenGL ES...
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!)
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'm not sure this discussion is going to grow much moreYep.
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 uselessThis 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:
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:
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.If the patches were created with git format-patch, then they will have him as the author and you as the committer. If they just send you a diff instead of a proper patch, then author information is lost and you have to specify it using --author when committing. It looks like this when done (https://github.com/mjbshaw/FFmpeg-OpenJPEG-J2K-Encoder/commit/60f06f986f81c5aa0497c4fa189f50a504896c81).
but it will probably save Laurent's time overall.Yep, that was my main concern.
I find this part questionable, because it seems to me we're talking about:I spoke about tiny imperfections, not big issues that have to be fixed in order to make the pull request merge-ready.
- dropping a comment on github
- merge the pull request, open your development environment, make the changes yourself and commit them.
Line 25: Use if (x) instead of if(x)instead of just fixing those points myself. As soon as there are a lot of such issues (which is likely in a bigger feature request or bugfix), one wastes a terrible amount of time at formulating corrections. If a point is overlooked by the pull requester, I have to write another comment. Each time, I have to look at the code (or at least the diff) to check if everything was implemented correctly. I always have to wait for the requester to adapt my suggestions. If he is inactive, the whole progress stalls. And I still don't see whitespace inconsistences because of web interface limitations.
Line 35: Comment should be worded "// After closing the window" instead of "//window close"
Line 60: Break the line before the third function argument
Line 80: Call template argument T, not Type
Line 92-98: Group the draw() calls together, and clear() and display() with an empty line in between
Line 111: File ends with newline
Do you really think the main motivation of contributing is to appear in the commit lists?I don't think it's a primary motivation (nor should be), but it's a form of positive feedback. It's encouraging to know you've made a positive impact.
I don't know if it's good to go in that direction, it might lead to people saying "look, I am part of the SFML development"But aren't they? They may not be a primary/core developer or a maintainer, but they can certainly claim to have helped and contributed.
or competitions between users concerning who contributes most, and a lot of trivial commits of which the merge overhead outweighs the feature -- in other words, people who only contribute for the sake of being visible in the commit list.I've never had such "dick measuring" (sorry) be an issue in the open source projects I've followed and contributed to. I really don't think that would be an issue.
Also, the repository owner shouldn't be under the pressure of applying a commit, because not doing so or implementing it himself (which would be faster in some cases) would appear as "unfair compared with others".Oh sure, trivial things are easier to reject, IMO.
Of course, this is a pessimistic view, but eventually there will be a few people acting like this.I doubt it'll be problematic.
In my opinion the motivation should generally be a different one, namely progress.In case it wasn't clear, I don't think your name in the commit history should be your real motivation. Progress should absolutely be your primary motivation. But positive recognition can certainly be encouraging and help strengthen your motivation. But even if someone was purely motivated by recognition... well as long as SFML progresses, I don't really care.
And I still find the points in my last post important, but of course it's up to Laurent how this is handled. But you can be sure, even if the SFML conventions are listed again and again, many people will not follow them exactly.True, but if a clear style/conventions guide was available, all it would take is a one sentence "Make sure you're adhering to this style guide; rejected until fixed." and then you don't have to say any more about the trivial stuff. Either they'll fix it, or it will stay rejected.
In the case of smaller contributions, constantly rejecting commits and hinting to the mistakes takes up much more time than implementing things oneself.If you've got a clear style guide, again, you can just link to it and say it's rejected until fixed. Make them figure it out. It'll weed out the serious from the not serious.
I doubt it'll be problematic.Yes, as said it's pessimistic. I just wanted to note that there might also be negative effects, how this looks with this specific project and its users is a different question.
True, but if a clear style/conventions guide was available, all it would take is a one sentence "Make sure you're adhering to this style guide; rejected until fixed." and then you don't have to say any more about the trivial stuff. Either they'll fix it, or it will stay rejected.Ok, if it is realized this strictly, it might work. And in the long term, being strict is probably the only way to go.
Problem is time, as usual.Would it help if we (the community) wrote a style guide (which you would correct and revise when you had time), and then once you're satisfied with it then it's done? Once it's all written, it should be pretty easy to integrate it into the website (of course, this wouldn't be done instantly, but I'm trying to find ways to help out).
I'd like to have the time to write a complete style guide for contributors, but I don't. Sometimes I take the time to tell people what to change so that their pull request can be merged, sometimes I don't because I really have no time. I know, it's so sad :'(