<div dir="auto">I wonder if we are limiting ourselves by saying they must have the following experience: <div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">What we really need is someone who can communicate well and understand the end user requirements. In my experience this is much more important than having coding skills in XYZ. These can be learnt. One problem I saw with computer science graduates was their inability to grasp what the end user really required. My best two resources were a secretary who did a one year course in programming then she ended up with me for some work experience. I could teach her the programming no problem but her soft listening skills were excellent. She could pick up on things I missed in a meeting. The other one was a construction worker who had run projects in the construction industry. In Canada most construction closes down over the winter months and the workers go on unemployment. He was given the choice of no benefits or retrain as a programmer. Again he got picked up on work experience and with his project management experience it worked well. It still took him a couple of years to get really proficient in the particular programming language we were using.</div><div dir="auto"><br></div><div dir="auto">One of the ways that could be used to bypass the restrictions on hiring someone was to find an obscure programming language that was still on the federal government books then request experience in that. The tale is still told of a student who arrived and on their first day was taken from person to person to gain experience in the subject. An hour each and at the end they indicated on their application form they had experience in three different things which allowed them to be screened in.</div><div dir="auto"><br></div><div dir="auto">I suggest if you want someone to stay then if you can avoid a new graduate who will be looking to gain experience before moving on. Have you thought about career progression? Programmers are basically often put in a dead end job. If you're the only programmer then there are no promotions. Have you thought about talking to the Nepal or other group and paying them to take responsibility for id? That way the programmer would have others to talk to about problems and if the workload suddenly grew or the programmer needed maternal or parental leave there would be someone to cover for them.</div><div dir="auto"><br></div><div dir="auto">I picked up a number of programmers who lost their jobs when the software they were familiar with disappeared when the mainframe hardware was replaced. It took them a couple of weeks to come up to speed but they were solid and very experienced programmers.</div><div dir="auto"><br></div><div dir="auto">I suggest experience in using Visual Studio in a development environment would be advantageous. The debugging and testing tools mean the programmer can be much more productive. I understand there are religious arguments against using Microsoft tools but they are very effective and if my memory serves me correctly there are tools in there for optimising the code. Translation it will work using fewer resources or on cheaper machines.</div><div dir="auto"><br></div><div dir="auto">Cheerio John</div><div dir="auto"><br></div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 3, 2021, 15:57 Tobias Knerr <<a href="mailto:osm@tobias-knerr.de">osm@tobias-knerr.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 27.04.21 21:05, Mateusz Konieczny via talk wrote:<br>
> Are there plans to find maintainer who would be taking care of iD <br>
> without expectation of<br>
> full time development?<br>
<br>
We are open to multiple options, including a full-time maintainer or <br>
several part-time people – we would make this dependent, in part, on <br>
what arrangements potential candidates are interested in. (Check my <br>
recent my message to osmf-talk as well.)<br>
<br>
If the goal would be just to bridge the time until we have found a <br>
candidate (or candidates), I'm not sure someone who isn't already <br>
actively working on iD core code to ramp up quickly enough for this to <br>
be practical. As you say, the situation may be different for the <br>
auxiliary repositories:<br>
<br>
> Also maybe a separate maintainer for <br>
> <a href="https://github.com/openstreetmap/id-tagging-schema" rel="noreferrer noreferrer" target="_blank">https://github.com/openstreetmap/id-tagging-schema</a> <br>
> would make sense and make easier to find full time developer for iD?<br>
<br>
Personally, I feel it could make a lot of sense to give commit rights to <br>
existing volunteer contributors of such repositories, both to reduce <br>
disruption until a replacement for Quincy has been found (by preventing <br>
a backlog of issues and PRs from building up) and to perhaps to continue <br>
assisting the future maintainer.<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
talk mailing list<br>
<a href="mailto:talk@openstreetmap.org" target="_blank" rel="noreferrer">talk@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk" rel="noreferrer noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk</a><br>
</blockquote></div>