Attendees
| IRC nick
|
Real name
|
| zere |
Matt Amos
|
| SteveC |
Steve Coast
|
| iandees |
Ian Dees
|
| tomh |
Tom Hughes
|
| RichardF |
Richard Fairhurst
|
| Firefishy |
Grant Slater
|
| emacsen |
Serge Wroclawski
|
| apmon |
Kai Krueger
|
| Zverik_h |
Ilya Zverev
|
| SteveSn_ |
Steve Singer
|
| mkl1 |
Mikel Maron
|
Summary
- What are the barriers-to-entry for new developers?
- Getting the Rails site up seemed to be a common theme. It seemed the general consensus that the documentation isn't very good and the dependencies are too hard to install. (Zverik, emacsen & zere: try installing Rails site and getting the unit tests to pass, recording the steps & difficulties along the way)
- There was discussion of making a dev VM available, but worries about keeping it up-to-date and swapping problems with installing the software for problems with dealing with the VM.
- More face-to-face developer meet-ups were proposed, but there were some worries that we do not yet have the numbers of developers to make it work.
- Many other ideas were proposed, but there was not enough time to discuss them all.
- Are there small projects (perhaps mentored?) which new developers can take on?
- It was agreed that trac, the OSM bug tracking system, is a bit of a mess - it has many out-of-date issues in there, and is in need of a bit of a clean-up. (SteveSn_ and iandees: look through trac and try to clean it up)
- Categorisation and write-up of some small projects could go on the wiki and serve as a starting point for developers looking to get involved.
- There was discussion of how priorities should be set.
- What can be done to improve the usefulness of communication between developers and users?
- Mkl1 pointed out that there is a group of people organising themselves on the design mailing list, which could be a good avenue for communicating with users and experts in the design area.
- The dev mailing list is probably too unfocused for user-developer communication. There was talk of setting up a separate mailing list for this to provide a forum for transparent discussion.
IRC Log
18:03 <@zere> i'm Matt Amos, who are you?
18:03 < SteveC> I'm Steve Coast, I once wrote some OSM software
18:04 < iandees> i'm Ian Dees. I wrote some software to read SteveC's software's output.
18:04 < TomH> I'm Tom Hughes, I write, maintain, deploy and generally wrangle the web site
18:04 < RichardF> I'm Richard Fairhurst. I write Potlatch (as do others).
18:04 * Firefishy is Grant. I do hardware.
18:05 < RichardF> and I'm waiting for the first Spartacus joke.
18:05 <@zere> it's ok, this isn't an AA meeting. you don't have to admit to anything ;-)
18:05 < emacsen> I'm Serge. I read the codes that wrangle the interwebs.
18:05 < apmon> I am Kai Krueger and I occasionally contribute to the rails_port and other OSM software
18:07 <@zere> ok... we'll let the lurkers identify themselves later.
18:07 <@zere> first item on the agenda is "what are the barriers-to-entry for new developers?"
18:07 < SteveC> are lurkers allowed in WSG etc?
18:07 * Firefishy waves at our tor friends.
18:07 -!- Zverik_h [~Miranda@176.14.106.158] has joined #osm-ewg
18:07 < SteveC> I though they got kicked
18:08 < TomH> do we care? aren't we trying to be inclusive?
18:08 < TomH> I know SWG gets a bit picky about such things but I don't see a need here
18:08 < Firefishy> Let move on...
18:08 < Firefishy> *Lets
18:08 <@zere> i'm happy to let people lurk. i think it's fair to ask people to identify themselves if they wan't to contribute, though.
18:08 < SteveC> I say kick them, not nice to have potential trolls lurking.
18:09 < Zverik_h> Hi! I'm wondering what this WG is about, don't kick me :) I'm a programmer from Russia, sometimes I implement little things — like Relation Toolbox plugin
18:09 < Firefishy> ping AndiPersti, osmisto, SteveSn_
18:10 <@zere> let's see how it goes. better to start off inclusive, imho, and not assume a priori that there'll be trouble.
18:11 < RichardF> ok. are we talking barriers to entry then?
18:11 <@zere> hi Zverik_h! we're here to try and find ways to make it easier to develop with OSM. who, if you don't mind my asking, are you?
18:11 <@zere> RichardF: yes, in a round-about way ;-)
18:11 < SteveC> getting the full stack up for the server is kind o f aPITA
18:11 < RichardF> I'll fire off some possibilities just to get started then...
18:11 < Zverik_h> zere: well, most of it is here: http://wiki.openstreetmap.org/wiki/User:Zverik
18:12 < RichardF> 1. difficulty of setting up dev environment (Rails port, Flex for P2, etc.)
18:12 <@zere> we've already had a suggestion that simply getting the rails_port up and running is Hard. what can we do about that?
18:12 <@zere> Zverik_h: thanks!
18:12 < SteveC> release a virtualbox VM With everything in it?
18:12 < RichardF> yeah, I've heard suggestions that some form of VM would be good.
18:13 <@zere> sure. but that does go out-of-date pretty quickly. can virtualbox VMs be generated automatically?
18:13 < RichardF> could also be worth making an effort to be more tolerant with gem versions etc.
18:13 < emacsen> either what SteveC said (which is probably easiest) or a chef solo config, which will be more transparent
18:13 < SteveC> well it can selfupdate on boot
18:13 < iandees> perhaps some prior art: Stamen's map box/tile box? Also, there's a Summer of Code project with the hope of making it easier to install mapnik/db stuff via packages.
18:14 < Zverik_h> speaking as windows user, the main problem with rails_port is that there is no installer, the language is uncommon... the two main problems are: no installer, the language is uncommon (not python or java, for example) and it is not user-friendly
18:14 < SteveC> putting on my marketing hat though - before going to this vast effort you want to identify who the people are that will magicaly appear once there is a VM. Are we sure they exist?
18:14 -!- CGI376 [~4d08a55d@shenron.openstreetmap.org] has joined #osm-ewg
18:14 <@zere> presumably a decent selfupdate is hard, too. in the situation where people already have changes to their local copy
18:14 < TomH> (a) is VirtualBox the best choice - probably depends on what the expected host OS is
18:14 < TomH> (b) somebody will have to be ready to keep the thing up to date as dependencies change
18:14 < SteveC> (b) I nominate Tom
18:14 < TomH> selfupdate?
18:15 < Zverik_h> wouldn't it be hard to configure network connections for virtualbox?
18:15 < TomH> SteveC: no way, and certainly not if it's VirtualBox
18:15 <@zere> i.e: doing a git update on boot, i think SteveC was suggesting.
18:15 <@zere> and maybe not just git.
18:15 < SteveC> But, seriously, are new devs the #1 goal and if so, are we sure that a VM is the #1 thing to work on?
18:15 < TomH> I thought new devs was the point of this WG
18:16 < RichardF> I'm probably in a minority in that I use OS X rather than Linux, but I find the biggest problem with setting up rails_port is the dependencies
18:16 < SteveC> and not, say, weekly help sessions, or videos, or free chocolate for devs....
18:16 < emacsen> no one else AFAIK tries to do that kind of self-update thing, because it's hard. But I think if we do the chef thing, we can make images quick and easy.
18:16 < TomH> but maybe I misunderstood what you wanted?
18:16 <@zere> to be honest, it might be easier to work on the installation instructions for different OSses.
18:16 < iandees> zere: +1. the install directions aren't that easy to follow
18:16 < RichardF> e.g. rmagick - that takes serious amount of heartatche to install, and I _think_ all it does is create thumbnails of GPS traces; would be good if it was optional
18:16 < RichardF> s/atche/ache/
18:16 < SteveC> RichardF thats why virtualbox is nice. rmagick is horrific on a mac, trivial on a ubuntu VM
18:17 < TomH> RichardF: actually I suspect all it is used for now is resizing user images
18:17 < RichardF> TomH: ok, interesting
18:17 < SteveC> TomH: I figure it's broader than just getting new monkeys to the typewriters, it's also about what to type.
18:17 < RichardF> SteveC: /me nods. assuming there are good instructions for virtualbox somewhere.
18:17 < TomH> well sure, but getting them there is the first step
18:17 < SteveC> RichardF: Virtualbox is super trivial
18:17 < Zverik_h> can it be replaced with imagemagik? (if I understand it correctly)
18:17 <@zere> SteveC: sure. but that's also on the agenda, so let's leave it until then.
18:18 < TomH> Zverik_h: it is imagemagick (ruby wrappers)
18:18 <@zere> Zverik_h: rmagick is the ruby bindings to imagemagick (or graphicsmagick)
18:18 < Zverik_h> ah, ok. I'm not familiar with ruby. We need more ruby developers in the project :)
18:18 < SteveC> ok how about this, is a VM the best #1 to work on for new devs? +1 for yes, or -1 & reason if you have a better idea?
18:18 <@zere> or more people to learn ruby - iirc, one of the reasons that RoR was used is that ruby is an easy language to learn.
18:19 < SteveC> python without the tabs
18:19 < RichardF> I'd agree with that - I like Ruby as a language, the bit I don't like about it is all the gems shit
18:19 < RichardF> and if we have a VM that eliminates the latter problem
18:19 <@zere> -1 VMs are nice, but working with them (e.g: guest-to-host networking) is a whole other problem that we don't need.
18:19 < Zverik_h> then, we probably need instructions also on setting up IDE for this particular ruby project, links to short tutorials, explanations how the system works
18:20 < TomH> RichardF: for a about a week yes, then one of the gem dependencies changes and it all goes to shit
18:20 < RichardF> TomH: oh :(
18:20 < TomH> unless somebody rebuilds the VM
18:20 < RichardF> gems suck
18:20 < TomH> well it would be no different if we were talking apt's, or rpms, or CPAN packages, or....
18:20 < emacsen> May I suggest we table the discussion of how much people love/hate Ruby?
18:21 < emacsen> Presumably whoever makes the image, however they make it, can handle that issue
18:21 < iandees> What about packages of some sort? "sudo apt-get install openstreetmap-server" would be pretty neat and perhaps more useful than updating a VM every so often
18:21 < SteveC> Another thought - are all the Devs basically in London / UK ? Maybe there are more fertile places to find devs like other countries. Therefore, having all the hack weekends in London is just preaching to the converted?
18:21 < emacsen> iandees, that's kinda what I suggested re: chef.
18:21 < Zverik_h> how many people here installed, compiled and run rails_port?
18:21 <@zere> SteveC: try and stay on-topic, pls.
18:21 < emacsen> iandees, you can basically make it a two liner of install chef and run a script.
18:22 < SteveC> zere: what the fuck is the topic?
18:22 <@zere> what are the barriers to entry for new developers?
18:22 < SteveC> I thought we were discussing how to get devs
18:22 < SteveC> Like, all the hack weekends being in london and karlsruhe? is that not a barrier?
18:23 <@zere> are you saying that the availablility of local face-to-face developer meetings is a significant barrier?
18:23 < SteveC> Of course, it is super helpful to have a hands on 'heres how you do this' lesson, isn't it?
18:24 <@zere> do you think that would help more than, say, having better rails_port install docs, or having a pre-setup VM?
18:24 -!- banana [~627dd91b@shenron.openstreetmap.org] has joined #osm-ewg
18:24 < iandees> i think we were talking about how getting dev tools installed is a significant barrier and were discussing options to deal with that.
18:24 < Zverik_h> It seems like two or three people. Why don't we - those who are not familiar with ruby - try to prepare the dev environment, change some little thing and try to run it - and see what was hard. Then discuss it (not necessarily here) and make instructions, step by step.
18:25 < SteveC> in-person is huge, plus going ot the pub and all the community side of it
18:25 <@zere> Zverik_h: that sounds very helpful.
18:25 < Firefishy> Zverik_h: +1
18:25 < TomH> yes, but it kind of needs some existing developers in the area to bootstrap it
18:25 < Zverik_h> because if we make VM, then we are getting one more problem, not solving anything
18:25 < emacsen> Zverik_h, +1
18:26 <@zere> i agree that in-person is much better. but since the problem is the low number of devs with that knowledge, then it seems like a chicken and egg problem to start hosting hack weekends where there aren't currently any hackers. or have i missed your point?
18:27 < SteveC> well there might be specific events, like SOTM where we could run something with a high probability of success
18:27 <@zere> SteveC: and i'm sure you'd be the first to acknowledge that face-to-face doesn't scale very well. especially if we're missing the basics, like install instructions, VMs, video tutorials or whatever.
18:28 < SteveSn_> hi, sorry for being silent when pinged before,was in a $work meeting that ran over
18:28 < SteveC> I'm just trying to point out there are other things worth looking at and this narative jumped on the first one to present itself
18:28 -!- rweait [~nerd@66.11.182.154] has joined #osm-ewg
18:28 < RichardF> well, whatever the merits of a face-to-face, using it to install stuff is _never_ a good use of time - you end up spending the entire day arguing with dependencies, struggling with the wifi, etc.
18:29 <@zere> cool. and i'm sure noone is saying that more hack weekends isn't better. but maybe it's not a fundamental problem?
18:29 < RichardF> so even if we do have hackdays everywhere, we need easy installation first
18:29 <@zere> RichardF: like at the last hack weekend? :-P
18:29 < RichardF> zere: like at pretty much everyone I've ever been to ;) OTOH, AOL's Ethernet connection is lovely...
18:30 <@zere> Zverik_h has generously offered to look into the install and report back on what problems he encounters. would anyone else like to do the same, preferably on different OSses?
18:31 < Zverik_h> suddenly, everyone went silent :)
18:31 < emacsen> I'll do Ubuntu and or Centos if that's not Zverik_h's target
18:31 < Zverik_h> I'm on windows
18:32 <@zere> thanks, emacsen. anyone else would like to do Mac OS? (looks at RichardF)
18:32 -!- banana [~627dd91b@shenron.openstreetmap.org] has quit [Quit: CGI:IRC]
18:33 <@zere> silence from the galleries. i'll take that as a no.
18:33 < iandees> no access to the OS, sorry :(
18:33 < emacsen> well why don't we start there then. We don't need to cover all bases all the time
18:33 <@zere> i have access to a Mac OS machine, so i'll try that one.
18:33 < RichardF> zere: I think I have rails_port installed on all my Macs already, I'm afraid...
18:33 < Zverik_h> Are we talking about production or development environment? I mean, we could all just install it on our home PCs or laptops...
18:34 <@zere> development, i think. not that there's a massive difference.
18:34 <@zere> so, to grab the git repo for OSM rails and get it to pass the unit tests?
18:35 < Zverik_h> yup. To change some constants, run it and see everything works
18:36 < Zverik_h> (and remember how we did it :)
18:36 < iandees> not sure if you can see this, but this is one of the OSM GSoC projects this summer: http://www.google-melange.com/gsoc/project/google/gsoc2011/parveenarora/12001
18:36 < iandees> oh, their target is to get a tile server going. nevermind.
18:36 <@zere> so far we've had these ideas: 1) pre-cooked dev VMs, 2) install documentation, maybe incl. videos, 3) face-to-face meetings. these are all good ideas, but shall we have a show of e-hands to see which we think is most important? or put them in order or something?
18:36 <@zere> and any other ideas to add to that?
18:37 < SteveC> more videos
18:37 < SteveC> webinars
18:37 < SteveC> dev podcast
18:37 < SteveC> dev blog
18:37 <@zere> personally, (and i'll admit i'm not exactly the target market): 2, 1, 3 at this time.
18:37 < SteveC> special session like Andy Allan did on getting up and running at SOTM
18:38 < SteveC> formalise the team so people know what the requirements are to have a patch accepted
18:38 < SteveC> lay out what the EWG coding goals are
18:38 < SteveC> bug bounties
18:38 < SteveSn_> I also see 2 as a big one. If you can reduce the number of dependencies 1 becomes less of an issue
18:38 < emacsen> SteveC, whoah maybe a little too much formalization? Each group is different
18:39 < SteveC> It's a list of ideas
18:39 < SteveC> please treat it as such
18:39 < SteveC> or, just shoot them down, up to you!
18:39 < emacsen> gotcha. just brainstorming. that's cool
18:39 < SteveSn_> is there a list of patches/features that are generally accepted as desirable that need people to work on them?
18:39 <@zere> yeah, maybe it's time to move on to the next item, unless anyone would like to do the "show of e-hands"?
18:40 <@zere> SteveSn_: that's the next item, in fact ;-)
18:40 < SteveC> zere why did you ask for ideas if you just want to move on?
18:40 < iandees> zere: i think docs is the most important and we've had people volunteer to get started on reviewing existing stuff. the other things are good ideas, too.
18:40 < Zverik_h> are we discussing just rails_port, or OSM development in general?
18:41 <@zere> SteveC: gotta keep moving. we don't have infinite time.
18:41 < TomH> SteveSn_: well there's trac... but you probably need to pick and choose as there's a lot of noise
18:41 < RichardF> I'm with SteveSn_: would be good to reduce dependencies where we can.
18:41 <@zere> Zverik_h: rails_port at the moment, but we're not limited to that.
18:41 < SteveC> okay so this isn't really about thinking this through, it's more about whatever random thing is decided... that's kind of odd
18:42 < Zverik_h> There were a lot of ideas, but most programmers just need a working system and IDE to change little things and see how the system reacts. Most features grow from those little changes.
18:42 < Zverik_h> So, the simple instruction (and simplified installation with dependencies problems solved) should do.
18:42 <@zere> SteveC: if you're not trying to be helpful, please leave.
18:43 < SteveC> I was being helpful, you asked for ideas
18:43 < Zverik_h> But I cannot say anything specific, because I even haven't read the wiki page on rails port, sorry :)
18:43 < SteveC> then ignored them all, so I'm asking why?
18:44 <@zere> hmm... i don't think there really is an IDE for rails... i think intellij idea can do rails, but i'm not sure there's such a thing as a standard IDE that most devs currently use.
18:44 < SteveC> you could even say something like "why dont we make a list fo next time"
18:45 * Firefishy is tired. I'm off home...
18:45 <@zere> ok. let's thank SteveC for his ideas and come back to them next time. i'm worried that we're running out of time and haven't got off the first agenda item yet.
18:45 -!- Firefishy is now known as Firefishy_
18:45 -!- SteveC [~627dd91b@shenron.openstreetmap.org] has quit [Remote host closed the connection]
18:45 < Zverik_h> zere: I guess most IDEs can do rails. Netbeans can.
18:46 < Zverik_h> What are other items?
18:46 <@zere> the next one is "are there small projects (perhaps mentored?) which new developers can take on?"
18:47 < iandees> the editors seem to be the best place to look for those kinds of projects
18:47 <@zere> we've already touched on this - there's a lot of noise in trac with all the bugs there. is there anything we can do to de-noise that, or summarise the tasks which are small enough for someone to get started with?
18:48 < SteveSn_> a) Add a field to trac for estimated development complexity, b) a wiki page of TODO items with some marked easy
18:48 < Zverik_h> is it a task of finding new developers? "we've got one si-i-imple problem, could you help with just that?" (and then one more, and more)
18:49 < emacsen> I think that's an excellent idea
18:49 < TomH> well stuff there will range from being completely out of date, to pie in the sky via things which are sensible but nobody has been interested enough to do and things which are just insane
18:49 < iandees> yes, both of those are good thoughts. a short list of "most wanted" bugs/features would be great
18:49 < emacsen> A list might be, but a request on a list would be up to date, and might get people to help out
18:50 < TomH> who decides what is most wanted?
18:50 < mkl1> and grouped by component (if they aren't already). it's good to have a vision where a whole set of features might go.
18:50 < emacsen> "I need X. This would be a good task for a new person"
18:50 <@zere> yeah. i think (and feel free to disagree) that one problem with recruiting people is that making any change seems like taking on this massive monolithic task. i thought if we could pull out some short tasks, write up a bit like "start looking in this place" then it'd be easier to get started
18:50 < mkl1> like i was quite interested in pushing on the history page. and would be willing to support a new developer to get to grips, if we focused on something like that
18:50 < TomH> I'm very reluctant to go by what end users most ask for to start with - there needs to be some sort of quality control on the suggestions
18:50 < RichardF> TomH: +1
18:50 < mkl1> (btw, hi i'm mikel and i'm a lurking troll)
18:51 < mkl1> agreed, we should prioritize
18:51 < emacsen> See, I think a list will get obsolete fast, as has happened before
18:51 < SteveSn_> TomH: +1, going off and coding a feature for a list only to find out that the community doesn't think the feature is a good idea and it will never be committed is a great way to chase away developers
18:51 < iandees> "we" = the leaders of the project in question. e.g. TomH for rails_port, RichardF for P2, etc.
18:51 < emacsen> so a more informal approach may be in order
18:51 <@zere> sure. priority shouldn't be a matter just for people submitting bugs/features to decide - but what's a better way?
18:52 < TomH> well maybe we need some volunteers to go through trac and maybe close some out of date/nonsense stuff and also make a list of tickets that are worth organising into a list?
18:52 < emacsen> a developer has a task, and they just try to reach out before fixing it
18:53 < RichardF> (I'd love a user/developer distinction in trac - to make it not just a random wishlist, but actually usable as a priority list)
18:53 <@zere> do we have any volunteers for a trac cleanup?
18:54 < SteveSn_> I can go through and try to close and things that look like horrid ideas or aren't feature requests
18:54 < iandees> i can volunteer to look through trac
18:54 <@zere> awesome. thanks SteveSn_ and iandees :-)
18:54 < RichardF> +1
18:54 < iandees> however, i'd like the goal to be "close stuff that's obvious, ask about non-obvious stuff"
18:54 < TomH> if you add tickets that look useful to a wiki page or something then we can try and categorise them
18:55 <@zere> ok. and we can take a look at how that's going at the next meeting, maybe.
18:56 <@zere> the final agenda item (in our final 5 mins...) is "what can be done to improve the usefulness of communication between developers and users?"
18:57 < RichardF> give lessons in clue to users. give lessons in tact to developers.
18:57 < Zverik_h> trac needs registration. For most users this is a problem. We have oauth, why not connect trac and osm, so users could add new tickets in two clicks?
18:57 <@zere> this touches on what we were saying before, but i've heard it many times that trac isn't particularly friendly for the user. and to make matters worse, it's not exactly perfect for developers either.
18:57 < RichardF> speaking purely personally, of course.
18:57 < RichardF> Zverik_h: it uses OSM login
18:57 < TomH> Zverik_h: our trac uses osm logins!
18:57 < Zverik_h> oh. :)
18:57 < TomH> and oauth is NOT A LOGIN SYSTEM
18:57 * TomH channels zere
18:57 < mkl1> there are a group of people gathered around design issues on design@
18:58 <@zere> we've already talked about how trac gets filled up with "noise". is there a better way to do it?
18:58 < mkl1> they aren't users only, but can certainly represent the viewpoint of what might be priority from a user perspective
18:58 < RichardF> zere: "the developers' word is final"
18:58 < RichardF> maybe a report which excluded "wishlist" items would help?
18:59 < TomH> well part of the problem is that it's often easier just to ignore the ticket than try and reject it and wind up in a pointless argument with the reporter
18:59 < Zverik_h> still, I see a lot of people in russian community that want to have something improved, but not knowing how to report it. Usually I make trac tickets by myself. But I haven't seen a link to that trac from anywhere.. Or didn't look hard enough
18:59 < TomH> plus there of lots of "wouldn't be nice if..." tickets where the answer is "yes, but I don't especially want to work on it"
18:59 <@zere> would a system like help.osm.org work better? where there's a feedback system and karma whoring^W^W discussion?
18:59 < TomH> nooooooooooo!!!
19:00 < TomH> ye gads RichardF and I spent last night fending that idea off
19:00 <@zere> TomH: those may be perfect for beginner projects, if they're small enough.
19:00 < TomH> zere: sure
19:00 < SteveSn_> maybe we need to be have a status for tickets 'good idea, patch wanted' vs in queue to be worked on
19:00 < TomH> all a voting system will do is tell that 1000 people would like us to clone Google My Maps on the frontpage
19:00 < RichardF> SteveSn_: I think that's the "wishlist" status
19:01 < RichardF> or milestone, or whatever
19:01 < TomH> and 3000 mobile app users would like a higher tile download limit
19:01 < mkl1> you guys are talking about tweaking trac to handle requests better which is fine
19:01 < mkl1> but i don't see how that's really improving user-developer communication
19:02 < mkl1> are there ways to have substantive discussions with users who have clue?
19:02 < mkl1> it doesn't need to be wide open, can be a focused forum
19:02 < rweait> Have OSM devs give talks at programming-related conferences?
19:02 <@zere> so how can we take useful input whilst explaining why non-useful input is non-useful?
19:03 < mkl1> that's why i'm suggest design@ for some of this topics ... it's full of people with the right perspective, with clue and even development knowledge
19:03 < RichardF> josm-dev seems largely civil. so is potlatch-dev except when I have too much cider. would rails-port-dev help?
19:03 < mkl1> but were not talking about the implementation, we're talking about generation of ideas and prioritization
19:04 < mkl1> anything called *dev is not reaching out to users
19:05 < RichardF> I don't think that's necessarily true. JOSM and P2 users with clue seem to find their way to the lists.
19:05 < mkl1> ok that's good, i'm not entirely tuned in there
19:06 < SteveSn_> you can also reach out to users with a clue and invite them to join the -dev list
19:06 < mkl1> but it really needs to be a different kind of discussion, wherever it happens
19:06 <@zere> are mailing lists a good forum for these sorts of discussions?
19:06 <@zere> i.e: could we have a rails_port mailing list where people could come and discuss ideas or report bugs leave trac as a "dev-only" system?
19:07 <@zere> does that make it easier or harder for users? it would, i guess, reduce the cruft in trac...
19:07 < RichardF> I could see that helping.
19:08 <@zere> and it means that discussions are public and for everyone, rather than taking place on an obscure "comments" forum attached to an obscure trac ticket
19:08 <@zere> i know steve would mention uservoice, if he hadn't left.
19:09 < RichardF> the main danger is if the list becomes more like talk@ than josm-dev@.
19:10 <@zere> mkl1: do you think that moderation has been successful in preventing MLs degenerating into noise?
19:10 < mkl1> i do ... do you?
19:10 < Zverik_h> Oh, I've found an example. http://appbrain.uservoice.com/forums/39347-general
19:10 < mkl1> well at least it hasn't degenerating into so much nastiness
19:10 < Zverik_h> Do we have something like that?
19:11 < mkl1> and it doesn't take much effort ... just need to have the system in place
19:11 < TomH> no, because uservoice is exactly the sort of thing I'm opposed to
19:11 <@zere> so if we moderated dev more effectively, could we use that, or might it be worth setting up another mailing list.
19:11 < TomH> the "features decided by who can drum up the most sock puppets to vote" school of development
19:11 < RichardF> I think dev is never going to be focused enough
19:11 < RichardF> it's full of general mapnik/gsoc/install/osmosis/whatever issues
19:12 < mkl1> what about this design@ list?
19:12 < Zverik_h> TomH: sock puppets? Sounds like we've got problems before we've tried the system
19:12 <@zere> TomH: i would assume that anything from UV or similar would be filtered before they were acted on, right?
19:13 < TomH> trouble is I can see it being very hard to refuse something that has hundreds of votes
19:13 < TomH> no matter how silly
19:13 <@zere> mkl1: are you volunteering design@ to "garden" the UV suggestions?
19:13 < Zverik_h> I see that OSM developers usually have no trouble with that :)
19:13 < RichardF> yep, it gives voting legitimacy, and like TomH says we'll have 5000 people requesting a higher tile limit
19:13 < TomH> it will just lead to rows on the mailing lists about how we're not doing what the users want
19:13 < mkl1> zere: i don't think so :)
19:13 <@zere> awww ;-)
19:13 < mkl1> guys gotta run ...
19:13 < mkl1> when is the next meeting?
19:13 <@zere> next week?
19:14 < mkl1> cool
19:14 < Zverik_h> We can simply explain why something's not possible to implement
19:14 <@zere> this time is presumably ok for everyone who made it. any suggestions for alternative times to be more inclusive?
19:14 < Zverik_h> And if there's a flame war on a particular topic, it would stay in that topic, not affecting others
19:15 < Zverik_h> Right now if there's a troll-party in a mailing list, it consumes all of it
19:15 <@zere> i think part of the problem is that many things are a matter of taste and effort rather than possibility.
19:16 < Zverik_h> Ok. So we've got several people who determine what will be implemented and what not. Why not hide it, but make it a part of bug/feature-tracking process?
19:16 < Zverik_h> Right now it is solved by buring trac tickets very deep, right?
19:16 <@zere> which is why i thought i could cajole mkl1 into getting design@ involved. when someone says "1000 people think that the map should be blue" it takes someone with a design interest to argue that it shouldn't.
19:17 < mkl1> i can start the discussion there
19:17 <@zere> Zverik_h: right. so i thought this would work better maybe on a mailing list, so that the discussion around bugs is transparent and public.
19:17 < mkl1> has anyone kept minutes for today, so i can point them at what's discussed here?
19:18 <@zere> yep. still recording :-)
19:18 < Zverik_h> zere: as I said, the problem with mailing list is that for some people it's hard to participate in discussions, and it's easy for one dispute to consume the whole list
19:18 <@zere> if there are no objections, i'd like to propose next week's meeting at this time. so monday 29th at 5pm GMT. ok?
19:19 < TomH> whereas I find it hard to particpate in discussions on web forums ;-)
19:19 < emacsen> ok
19:19 < Zverik_h> But it simplier to keep track of how many users want something, and what exactly. It's like trac, only cleaner
19:19 < Zverik_h> zere: ok
19:20 <@zere> Zverik_h: if we had effective moderation then maybe the moderators could step in and say "this has become a more general / off-topic discussion, please take it elsewhere?". do you think that works?
19:20 < TomH> maybe I just don't know enough about UV
19:20 < Zverik_h> zere: we should not need such measures
19:21 < TomH> are you able to admins who can close a topic and say "no, not doing it"?
19:21 < Zverik_h> I don't know about it either, but I guess there are moderation tools
19:21 < TomH> I've only seen t from the user point of view
19:21 < Zverik_h> for example, a tab titled "rejected" :)
19:22 < TomH> Steve set one up and it immediatey got a load of things at the top that jst weren't going to happen
19:22 <@zere> dunno. there's an open-source UV-a-like called "vox populi" if you want to play with it http://www.eldos.com/vp/
19:24 <@zere> looks like we're winding down. thanks to everyone for coming. see you next week :-)