Attendees
| IRC nick
|
Real name
|
| apmon_ |
Kai Krueger
|
| ppawel |
Paweł Paprota
|
| tmcw |
Tom MacWright
|
| TomH |
Tom Hughes
|
| zere |
Matt Amos
|
Summary
- Getting started
- Discussed about the low variety of jobs available for newcomers: currently only the TTTs, which are generally large tasks and involve quite a bit of knowledge of internals.
- ppawel proposed a "Junior Jobs" system like KDE has, based on issues reported into bug tracking systems.
- AGREED: we can make these more visible by having a page on the wiki which links to a specific tag in the bug-tracker for each project, where those tags represent "getting started" jobs.
- zere proposed these future actions:
- To make a wiki page with a (non-exhaustive) list of OSM projects, each with links to their issue trackers.
- To find or generate links to tagged "getting started" issues on each of those.
- To help curate existing issues into "getting started" categories.
IRC Log
18:00:29 <zere> #startmeeting
18:00:29 <ewg-meetbot> Meeting started Mon Nov 26 18:00:29 2012 UTC. The chair is zere. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:29 <ewg-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:01:39 <zere> minutes of the last two meetings: http://www.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2012-11-12 and http://www.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2012-11-19
18:01:53 <zere> please let me know if there's anything inaccurate or missing there
18:02:53 <zere> as far as i'm aware, there are no matters arising from previous meetings
18:04:00 <zere> at the end of the last meeting we were discussing potentially making use of the bounties for TTTs to encourage participation. do we want to continue discussing that? does anyone have something they'd prefer to discuss now?
18:16:45 <ppawel> well... what is really the goal of ewg? shouldn't we go over the status of currently open tasks (TTTs I mean)?
18:17:35 <ppawel> I read "Guiding the development process by suggesting priorities and setting goals." - is setting up TTT list once a year enough?
18:17:43 <ppawel> (I don't know, I'm just asking..)
18:19:08 <zere> that's what we started with. i guess it's trying to strike a balance between having a relevant set of tasks which is up-to-date and changing on the one hand, and a stable set of tasks that can be used in a long term manner on the other
18:20:07 <zere> i could see, for example, if we updated the list every week then we'd probably have new stuff coming on and old stuff dropping off so quickly it would be difficult for anyone to get a hold on a task long enough to do all but the simplest
18:20:23 <zere> but maybe doing it over the course of a year is too long...
18:20:36 <zere> i dunno - what does everyone think?
18:21:46 <apmon_> Sorry, could someone past / send me the log for todays meeting so far, as I came late?
18:22:14 <ppawel> I agree that long/mid term goals are important. I'm just thinking how to make it more... well, more active I guess. now I'm watching the wiki pages for TTTs and there's not much happening. I know these are mostly long term tasks but somehow I feel that there's room for improvement
18:22:36 <ppawel> not sure what to improve though.. to make TTTs more 'visible' in some sense
18:23:03 <ppawel> but then again.. why make them more visible?
18:23:27 <ppawel> it's not like random people who stumble upon TTT list can just pick up and work on them
18:23:39 <zere> apmon_: it started pretty slow, you really only missed ppawel saying "well... what is really the goal of ewg? shouldn't we go over the status of currently open tasks (TTTs I mean)?"
18:24:02 <ppawel> I think what I'm missing is something like GNOME's "help wanted" bugzilla tag or some equivalent
18:24:16 <ppawel> I mean bugs/issues/tasks that are easy to find and relatively easy to do
18:24:20 <apmon_> Ah, OK, that is a nice and short summery... :-)
18:24:29 <ppawel> so new people (or people with free time etc) can just work on them
18:25:44 <zere> i guess there are several levels of "task" - each with their own needs. there are simple bugs (let's say equivalent to a few hours work) which need fixing but are perhaps too low priority to have been done already. that might benefit from a "help wanted" system
18:25:52 <ppawel> in KDE they call it junior jobs
18:26:25 <apmon_> ppawel: That was kind of the point of the TTT. They were supposed to be tasks that core developers had an interest in and would thus be willing to commit time in helping new people to get up to speed on these tasks
18:26:33 <ppawel> http://community.kde.org/KDE/Junior_Jobs
18:26:38 <zere> going up from there, there are larger tasks which could take a few days / weeks of evenings to finish off. those are (i think) more stable over time, and perhaps less suited for just picking up and doing.
18:26:53 <ppawel> apmon_, yes but TTTs right now are really huge tasks
18:27:22 <ppawel> and also they are not decomposed into smaller ones so there's no knowing where to start if you come in
18:27:58 <zere> as apmon_ says, TTTs were (i think) the largest class of tasks meaning possibly several weeks of hard work, and that we identified as probably not moving forward without some extra help. the idea of the TTTs page was so that we could communicate a very small number of "high priority" tasks that we wanted help on
18:28:15 <apmon_> I don't know. They are substantial tasks, but really not that huge code wise each
18:28:55 <ppawel> maybe not code wise but stuff like clickable POI's, history tab, routing - you will immediately hit infrastructure issues/questions
18:29:17 <zere> of course, as soon as the list was put up, it was probably pretty quickly out-of-date in terms of priority. but the feeling was that it was more helpful to people trying to find out what to do if the list wouldn't be changing all the time.
18:29:48 <zere> and yes, a large number of the TTTs hit infrastructure, which is why we tried to have "mentors" assigned to them who could help sort that out, or give guidance.
18:29:56 <ppawel> sure - maybe it should not be all about TTT, because this list should be pretty static I guess
18:29:59 <apmon_> Well, that is why it was supposed to be "Tasks the admins want" and not "tasks the community wants" as the idea was that they will actually get support from people to overcome the infrastructure issues
18:30:31 <zere> it's definitely worth looking back at the TTTs (maybe now, maybe Jan) and trying to figure out what worked and what didn't
18:30:37 <ppawel> perhaps EWG could kick off something like the KDE's junior jobs program above or Ubuntu's papercuts program
18:30:46 <zere> and better still - why worked and why didn't ;-)
18:31:55 <zere> how would you see "junior jobs" working in OSM?
18:32:13 <zere> i mean, our code bases are relatively small and inhomogenous compared to KDE's
18:32:43 <ppawel> not sure - I'm just struggling to see what would be the goal of this. I mean, as I see it, a lot of people work *with* OSM and not many people work *on* OSM
18:33:02 <ppawel> is that something EWG should try to change?
18:33:19 <ppawel> encourage people to work on osm.org website, on the API, main style etc?
18:33:53 <apmon_> Yes, that was the main point of EWG
18:34:36 <zere> that, and being a more interactive forum for technical discussions - when lists / bug trackers are insufficient
18:35:00 <apmon_> Figuring out the question of what motivates people to work on osm.org in their free time and what turns them off and pushes them to work on other projects instead
18:35:56 <ppawel> ok
18:36:00 <zere> not just osm.org code, although that's important. i think all the parts of the OSM software system can benefit
18:36:28 <zere> there are active communities around, for example, mapnik and JOSM. to a lesser extent, PL2 and so on.
18:36:54 <zere> but there are some bits of code which don't get so much attention, and that means that progress stagnates
18:37:56 <zere> so, yes, a "junior jobs" system might be a worthwhile experiment to get more people started. but we need to figure out how it's going to work
18:38:15 <zere> i mean, most of the time if there's a small bug then people will fix it directly...
18:39:21 <zere> ppawel: do you know how stuff gets into the JJ system? is it that bugs get reported by users and then a developer tags them as suitable for JJ?
18:40:38 <ppawel> the idea behind JJ in KDE is that maintainers of (or in general - developers of) some KDE project can mark a task as a junior job so that people can get started with that project
18:41:02 <ppawel> KDE of course has dozens of such projects (in bugzilla component terms), osm not so much
18:42:00 <ppawel> but I think it could work for osm as well.
18:42:55 <ppawel> however, I wonder if we wouldn't get more bang for our buck (=free time) just by making it easier to find stuff
18:43:06 <ppawel> I mean, right now you are faced with something like: https://trac.openstreetmap.org/wiki/OsmComponentReports
18:43:18 <ppawel> (and that is only after you find the trac, of course)
18:43:33 <ppawel> style-related tasks are under "mapnik" btw...
18:44:17 <zere> one difficulty i can see is that we don't have a single trac any more (well, we never really did), and that things are starting to spread out into their own issue trackers, github, etc...
18:44:38 <zere> do you think to be more effective that we should try and bring these back to a central issue tracker?
18:44:40 <ppawel> yes exactly
18:45:18 <ppawel> (yes exactly for your first sentence).. as for the second one... probably yes - but I thought how to do this, what issue tracker etc.. I've no idea for now
18:46:42 <zere> it's rather unfortunate - i really like the integration of the github issue tracker... but that couldn't possibly work for this, unless there's some way i don't know about to get a merged view of several projects' issues
18:47:26 <ppawel> yeah
18:48:21 <ppawel> the only software I can think of is JIRA - they seem to give out open source licenses to projects.. I like JIRA but I'm not sure it's a good fit for a project like OSM
18:48:57 <zere> TomH: does it happen that there are issues which get reported (either in trac or github) where you could say "i'm not going to fix this right away, it's low priority and not much code, i'll tag this so that someone could come along and get some experience"?
18:50:38 <zere> ppawel: i know... i don't like trac particularly, but it's not causing an actual problem right now. doesn't seem like a good enough reason to change / migrate.
18:50:45 <ppawel> perhaps the easiest way would be to just double down on trac
18:51:11 <ppawel> I mean clean it up a little plus redirect all traffic from github to trac
18:51:48 <ppawel> otoh, github seems to be working out pretty nicely for the openstreetmap-website project
18:52:33 <zere> yeah. it's the sad thing about redirecting from github issues to trac - (imho) github issues is far better! :-)
18:52:51 <ppawel> I agree
18:53:22 <ppawel> although I'm not sure how well they scale to a large number of issues
18:56:58 <ppawel> in any case, I think that before building something like junior jobs, the issue tracker 'problem' has to be sorted out, otherwise it will only result in more confusion...
18:58:11 <TomH> for the love of god no
18:58:23 <TomH> sorry, that was a response to jira
18:58:30 <TomH> ahdn't realised I wasn't at the end
18:59:51 * tmcw please don't double down on trac
18:59:58 <TomH> github issues are fine except that most people don't know about them, and there's no easy way to redirect people from using trac
19:00:13 <tmcw> using the osm trac?
19:00:18 <TomH> plus there's probably a fair few people would bitch about having to have a github login to raise issues
19:00:25 <tmcw> how about putting a notice at the top, and on issue submission pages?
19:00:49 <TomH> tmcw: that gets very messy though, given that it's onl for one small part of what trac is used for
19:00:59 <ppawel> http://www.gitlabhq.com/
19:01:07 <tmcw> what else is it used for?
19:02:07 <zere> ppawel: i think one of the advantages of github is that it's integrated - no need to run our own instance, have logins for that instance, etc...
19:02:21 <TomH> well look at https://trac.openstreetmap.org/newticket and see all the components
19:02:48 <ppawel> zere, yeah... I was just looking at what's new out there in open source issue trackers world.. gitlab looks like a nice github clone
19:03:01 <tmcw> Ah, so you mean other projects
19:03:18 <tmcw> Well, discourage people from submitting tickets for projects that have GitHub issue trackers?
19:03:38 <tmcw> And/or nag people who are still managing their projects in the svn/trac dungeon to do the 2012 thing
19:03:52 <zere> might the answer be a system which sits atop the various different issue trackers?
19:04:11 <ppawel> :)
19:04:18 <zere> i mean, the original thing we were looking for was a way to surface "simple" low-priority issues for people to get started with
19:04:52 <tmcw> A... list of projects in a wiki page or static html, plus a 'top ten tasks' for newbies?
19:05:09 <tmcw> and encourage people to use a 'getting-started' tag.
19:05:23 <zere> so it wouldn't have to necessarily be integrated into the issue trackers themselves, as long as there was a way to 1) get a feed of the data, and 2) signal to the system that an issue was suitable for beginners
19:05:44 <ppawel> zere, this may just as well be a simple list on the wiki.. but I think there's a reason why the discussion shifted to the general issue tracker topic... because currently it's a cluster****
19:06:46 <tmcw> why would this need to be automatic?
19:06:49 <zere> the wiki is fine for long-term stuff. but as ppawel pointed out earlier, the wiki doesn't get updated very often because of the human overhead in doing so.
19:07:07 <TomH> it's an interesting conundrum that the things most suitable for beginners are probably also the easiest and therefore the things that somebody else is most likely to knock off quickly as they come in...
19:07:41 <zere> if i've tagged an issue as "getting-started", then i figure i have to log into the wiki, edit, copy & paste some information from the issue tracker, etc...
19:08:01 <zere> then the same again when the issue is closed, or changes status
19:08:17 <ppawel> zere, yeah, it's pretty much guaranteed that a manual list will not stay in sync / uptodate / relevant and will die
19:08:18 <tmcw> huh?
19:08:24 <zere> basically, i don't think i could be bothered to do it, so i assume everyone else feels the same ;-)
19:08:34 <tmcw> want to get started with id? https://github.com/systemed/iD/issues?labels=get-started&page=1&state=open
19:08:50 <ppawel> awesome
19:09:00 <tmcw> there aren't that many projects, like 10 max, that we can honestly say people should contribute to if they're a noob
19:09:01 <ppawel> what about the website project? which has most of its issues in trac?
19:09:19 <tmcw> and if developers don't do their homework to get contributors, they won't, regardless of what we prop up
19:09:37 <zere> iirc, there are tags in trac too. and we could add those tags
19:09:37 <TomH> yeah I haven't really manged to come up with a very good set of tags for our github issues...
19:10:12 <zere> what i was asking TomH before was whether he comes across these issues often, or whether issues that are that simple are just fixed immediately
19:11:07 <apmon_> Does it really need to be simple things?
19:11:10 <zere> tmcw: sorry, i misunderstood - i thought you meant a list of "getting started" issues on the wiki, not a list of *links* to getting-started tagged issues on other sites
19:11:14 <ppawel> simple fixes that are best done by TomH are one thing
19:11:40 <TomH> zere: that's what I was getting at - if it seems simple there's a good chance I'll just do it...
19:11:44 <ppawel> but another class of issues is something that other developers probably won't ever come to
19:11:54 <ppawel> because they have other interests or whatever
19:12:03 <ppawel> example: language selector
19:12:09 <zere> apmon_: what else would it be for "getting started" other than simple? we can't very well ask people to "get started" on something complicated?
19:12:42 <ppawel> zere, I think junior jobs don't necessarily have to be objetively simple. we cannot teach people how to program...
19:13:14 <zere> i mean "simple" in the sense that the objective can be easily explained, and probably doesn't need deep knowledge of the existing system
19:13:15 <ppawel> what I see as a junior job is something that a component outside developer can pick up and work on without getting too much into internals, infrastructure, tracking down previous efforts etc.
19:13:16 <apmon_> One can get started on interesting features too, as the motivation to work on those might be higher
19:13:23 <ppawel> *competent
19:16:16 <ppawel> zere, yeah , so pretty much the same definition of 'simple'
19:16:52 <apmon_> I started rails_port development by implementing OpenID login. I had a proof of concept of it up and running in 2 - 3 days and that included learning rails. So I do think features of that kind of complexity are feasible to "getting started". But perhaps that does count as junior job?
19:17:12 <zere> i have 3 questions: 1) what makes a suitable "getting started" task, and how can we identify them? 2) do we already have many such tasks, or do they get added frequently? 3) what's the best way of communicating the availability of these?
19:17:51 <ppawel> apmon_, yes, that is a good candidate for a junior job in my book
19:18:57 <ppawel> zere, re 2: there are some in trac, new ones are not added frequently, mainly because not many people report anything (bugs, features)
19:19:41 <apmon_> OK, so junior jobs are a lot more "complex" than fixing a single trivial bug or so. Thanks for that clarification, as that wasn't clear
19:20:17 <ppawel> apmon_, I think they can be complex, yes. as long as they are relatively 'independent'
19:20:35 <apmon_> So instead of closing those kind of feature requests or assigning it to "the mystery coder", they could be assigned to "junior jobs"
19:21:18 <ppawel> well I would even go crazy and say that many wishlist pages from the wiki could be transformed into "real" issues, many of them as potential junior jobs
19:23:55 <zere> i'd be careful with that... there are many wishlist pages on the wiki that really aren't suitable features to have (e.g: just the wrong way to do it that'll cause problems in the future)
19:25:04 <ppawel> sure but there must be some wishlist items that are reasonable enough to put in an issue tracker, just to have it on the radar if not anything else
19:25:30 <ppawel> (and no, having it on 10 different wishlist pages does not bring such items on the radar, at least not for most developers... I think)
19:29:12 <zere> sure. i'm just saying that dropping everything which is on the wiki into trac won't actually improve the situation. stuff on the wiki needs to be filtered for feasibility and practicality, and whether it might clash with/uglify other features.
19:29:58 <zere> but yes, no doubt there are some sensible suggestions floating about (changeset comments springs to mind) that would be eminently suitable as "getting started" jobs, imho
19:31:11 <ppawel> so.. perhaps we could plan some actions? do you think going forward with the junior jobs (in whatever shape) is blocked by github/trac debacle?
19:31:57 <zere> i don't think it's blocked. it's not ideal to have more than one place to look for jobs, but it's not the end of the world.
19:32:18 <zere> what actions can we take? the first one that springs to mind is curating the tickets already in trac
19:33:19 <zere> which we've had a go at before... i think it's a pretty uninspiring action, but necessary.
19:35:34 <zere> ppawel: what do you think the next steps are?
19:36:48 <ppawel> I agree about organizing trac issues a bit better, closing outdated ones etc. I'm just thinking about your third question
19:37:06 <ppawel> I think that may be nearly as important as the issue tracker itself..
19:37:11 <ppawel> communication I mean
19:38:14 <ppawel> but I guess we should have something to communicate first :-)
19:38:49 <zere> yup. i think we can count on CWG to get a blog post or two out about it. which might help people find it on google... but not sure how to make this stuff obvious to people who are visiting the site. as you say, probably better to have something available before we make any noise about it
19:39:45 <zere> ok
19:40:14 <zere> first action: make a wiki page with a (non-exhaustive) list of OSM projects, each with links to their issue trackers
19:40:46 <zere> second action: find/generate links to tagged "getting started" issues on each of those
19:41:10 <zere> third action: help curate existing issues into "getting started" categories
19:41:26 <zere> sounds like a good plan? better to do it in a different order?
19:43:08 <ppawel> sounds good to me... perhaps looking at http://wiki.openstreetmap.org/wiki/Develop would be a good start
19:43:44 <ppawel> there really *is* a lot of stuff on the wiki, it's just... not discoverable? not sure.
19:44:42 <ppawel> well for one there is really no easy way to find this page
19:45:51 <zere> yes. a lot of it is not (easily) discoverable. further, a lot of stuff is simply out of date and has been superseded or obsoleted by something else. a lot of stuff is misinformed or ill-specified.
19:46:44 <zere> which is probably why issue trackers exist - if wikis worked well for this we'd have all moved to using wikis for issue tracking ages ago
19:49:21 <zere> ppawel: that "develop" wiki page is linked from the main_page... but even so, there are probably better ways to promote it. perhaps even taking it off the wiki would work better?
19:49:50 <ppawel> aah indeed it is
19:50:03 <ppawel> I grepped the main page for "dev"
19:50:06 <ppawel> and got nothing
19:50:14 <ppawel> but I see now there's a link called "create better tools"
19:50:38 <ppawel> I'd say it should be more along these lines: http://community.kde.org/Getinvolved
19:50:57 <zere> i have a feeling we've run out of steam for today's meeting... i'm not sure i'll get any volunteers for the actions.
19:52:08 <ppawel> I'll probably do some work on the wiki and triaging trac issues.. but I feel these will be ongoing tasks...
19:53:13 <zere> yeah, very non-SMART... thanks for taking a look. i reckon we can start next meeting by setting out the stall and seeing if we get any volunteers for perhaps smaller, more acheivable pieces
19:53:19 <zere> #endmeeting