[OSM-dev] OSMF Engineering Working Group inauguration

[Kai Krueger]

Hi,

as I in the end wasn't able to attend the irc meeting (got busy at 
work), I will write down my thoughts to the topics discussed today.

* Barriers for entry for getting started:

I agree that if setting up a development environment is too complicated 
it will stop contributers (e.g. it has stopped me from trying to 
contribute some minor i18n patches to P2), but I don't think the 
situation is that bleak for the rails_port.

At lest on a standard Ubuntu installation, I thought the step by step 
installation instructions were actually quite good and accurate. And so 
even though it might take a while to go through all the steps, it wasn't 
too difficult.

So the question is what part do people find too difficult/tedious? Is it 
that people use other operating systems / distributions, for which there 
are no instructions? Are there simply too many steps in the process for 
people to bother? Do the steps not work under some conditions? Do people 
not find the existing documentation?

The second aspect that didn't get mentioned during the irc meeting is 
that there is the osm dev server environment. Once you have a dev server 
account with db access, setting up a rails_port instance is actually 
pretty easy. You basically only need to download the source, extract it 
in a directory and update a few config files and you have a working 
rails_port instance up and running in your home directory with which you 
can experiment. All the dependencies on rails and gems have already been 
taken care of so you don't need to worry.

Are there things that can be done to make this resource even easier? 
Easier account creation? Better advertisement that this resource exists?


* Motivation to contribute

Given that currently pretty much everyone is working on coding in their 
spare time for free, imho having some form of (non monetary) reward to 
motivate people to put in the effort to contribute is important. Usually 
this is in form of seeing your code deployed and getting positive 
feedback from the users that they very much enjoy the feature.

For the first part (and partially second part) having a list of "top ten 
features / bugs that developers want help with" would possibly be a good 
start. If a feature is on that list, and the patch is reasonable, then 
hopefully chances of getting it deployed would be high. (and chances of 
getting told it is a stupid idea and will never get deployed anyway, 
lower). It also provides ideas for people who might want to help 
development, but might currently not have great ideas them selves.

With respect to the criticism voiced in the irc meeting, that such a 
list would likely be outdated and useless, well, recruiting new 
developers does require a bit of effort and if we can't even put the 
effort in to keep a list of top 10 wanted features up-to-date, perhaps 
it is not surprising that not many people start contributing to the 
rails_port.


The second part of the motivation "getting positive feedback from the 
users that the new features are appreciated" is perhaps much harder to 
solve. One possible way though would be to have a user oriented feature 
wish list a la uservoice (or better to say an open source equivalent). 
If a feature has e.g. a thousand up-votes and is the top _feasible_ 
feature on that list, I'd be a lot more motivated to spend my weekends 
coding that feature / enhancement / bug fix than if I don't know if 
anyone would even care about the patch or if the community would even 
think it is rubbish. But perhaps there are better ways of obtaining that 
feedback.



But overall, it seems like it was a reasonable  productive first meet 
for the EWG.

Kai


On 01/-10/-28163 12:59 PM, Kate Chapman wrote:
> Hi Matt,
>
> Just wanted to mention I'm interested in helping.  Sadly I am
> unavailable today, though normally I would be at the time selected.
>
> Couple thoughts I have about the rough agenda:
>
> * Barriers for entry for getting started:
>
> People seem to have issues getting the rails port working.  Perhaps
> creation of VM with development environment?  That would allow those
> who maybe can just do JavaScript and CSS still to contribute
> something.
>
> Documentation (this of course depends on the specific project).  Are
> there holes in the documentation that could be improved?
>
> * Small Projects that are mentored to get developers started:
>
> I don't have any great ideas about this.  I don't actively contribute
> to any of the main OSM projects by actually coding, though I'm willing
> to help mentor if there is a way that makes sense.  Are there
> individuals who come in and want to contribute code and don't map that
> need basic OSM mentoring?
>
>
> Thanks!
>
> -Kate
>
>
>
>
> On Mon, Aug 15, 2011 at 8:09 PM, Matt Amos<zerebubuth at gmail.com>  wrote:
>> the "Engineering Working Group"[1] is a new group set up with the
>> purpose of helping stimulate the development community surrounding
>> OSM. you don't need to be a developer to join - we're interested in
>> hearing from everyone and ideas are welcome. software enables us to do
>> the mapping we love, and to make use of the data we collect, so making
>> our software better is part of making OSM better.
>>
>> although IRC isn't a perfect communication medium it's easy to set up
>> and it's interactive, so i've set one up over at #osm-ewg on OFTC.
>> just to kick off, i suggest a meeting next week on:
>>
>>   Monday 22nd at 5pm GMT
>>
>> (5pm CEST, 6pm BST, 1pm east-US, 10am pacific-US)[2] to start the conversation.
>>
>> a very rough agenda for the meeting, including but certainly not limited to:
>>   * what are the barriers-to-entry for new developers?
>>   * are there small projects (perhaps mentored?) which new developers
>> can take on?
>>   * what can be done to improve the usefulness of communication between
>> developers and users?
>>
>> hope to see you there,
>>
>> matt
>>
>> [1] it's not necessarily the best or most descriptive name, but it'll
>> do for now. other suggestions include "Development Support Group" and
>> "Software Working Group".
>> [2] yeah, i know, but no matter what time is chosen it'll be bad for
>> someone. i suggest we start with this and i'm open to suggestions
>> about rotating the time or setting up other communication channels
>> which are less time-zone sensitive.
>>
>> _______________________________________________
>> dev mailing list
>> dev at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/dev
>>
>
>