New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Review onboarding #2291

Closed
pnorman opened this Issue Aug 18, 2016 · 25 comments

Comments

Projects
None yet
10 participants
@pnorman
Collaborator

pnorman commented Aug 18, 2016

We haven't really looked at this in a long time, and all of the maintainers are experienced enough that getting started is removed from what we do that we're not the best people to consider it. We should review our onboarding.

  • What unwritten knowledge do we assume? If we need to assume a certain level of linux, osm, CartoCSS, git, cartography or other knowledge, we should be explicit about it.
  • Does our current documentation work as a startup guide?
  • Is it clear to developer how to participate when their changes are being reviewed? Even if they're used to code reviews, cartography is a bit different. I think this was a problem in #2139 where the PR kept being expanded to cover suggestions that I would have rejected. Not all ideas suggested on PRs are good ideas and sometimes the appropriate response is "I looked at this but it didn't work because..." or "I want to keep this PR focused on ... not ..."
  • Is it clear to start out by keeping PRs small? Sometimes it takes experience to know the appropriate size of a "chunk" of changes and when changes really are related, but I'd much rather have PRs too small than too large. After all, it's trivial to merge the too small at the same time, but splitting up the too large is more work.
  • Is it clear where to get help with the basics? GitHub isn't exactly the right place for asking questions on getting started but we've used it for that.

@pnorman pnorman added the general label Aug 18, 2016

@matthijsmelissen

This comment has been minimized.

Show comment
Hide comment
@matthijsmelissen

matthijsmelissen Aug 19, 2016

Collaborator

Thanks for opening this issue, I'm very curious for the response from new or potential contributors.

Collaborator

matthijsmelissen commented Aug 19, 2016

Thanks for opening this issue, I'm very curious for the response from new or potential contributors.

@don-vip

This comment has been minimized.

Show comment
Hide comment
@don-vip

don-vip Aug 19, 2016

Something strange at first glance is the ownership of this repository. If you want maximal visibility as it is now, for a long time, the de-facto standard OSM style, shouldn't it be transferred to @openstreetmap organization?

don-vip commented Aug 19, 2016

Something strange at first glance is the ownership of this repository. If you want maximal visibility as it is now, for a long time, the de-facto standard OSM style, shouldn't it be transferred to @openstreetmap organization?

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Aug 26, 2016

Collaborator

Something strange at first glance is the ownership of this repository. If you want maximal visibility as it is now, for a long time, the de-facto standard OSM style, shouldn't it be transferred to @openstreetmap organization?

I've preferred not having it on the @openstreetmap organization. Part of this is because I don't know what being on that organization would entail, part of it is I view this stylesheet as the one chosen to be on tile.osm.org not the stylesheet for osm.org, and part of it is that it's fairly common for OSM software projects not to be on the openstreetmap organization. Examples include JOSM, taginfo, cgimap, and overpass.

The traffic information from GitHub is maintainer only, but we're getting >50 unique cloners and >1k UVs a week and plenty of activity on the issue tracker. I think it's an issue of converting that to contributors.

CC @geostonemarten and @Ircama as people who have recently gotten started

Collaborator

pnorman commented Aug 26, 2016

Something strange at first glance is the ownership of this repository. If you want maximal visibility as it is now, for a long time, the de-facto standard OSM style, shouldn't it be transferred to @openstreetmap organization?

I've preferred not having it on the @openstreetmap organization. Part of this is because I don't know what being on that organization would entail, part of it is I view this stylesheet as the one chosen to be on tile.osm.org not the stylesheet for osm.org, and part of it is that it's fairly common for OSM software projects not to be on the openstreetmap organization. Examples include JOSM, taginfo, cgimap, and overpass.

The traffic information from GitHub is maintainer only, but we're getting >50 unique cloners and >1k UVs a week and plenty of activity on the issue tracker. I think it's an issue of converting that to contributors.

CC @geostonemarten and @Ircama as people who have recently gotten started

@nebulon42

This comment has been minimized.

Show comment
Hide comment
@nebulon42

nebulon42 Aug 26, 2016

Contributor

Maybe a tutorial document for new developers might be useful. https://gist.github.com/nebulon42/e5f73e511d44726ef66c7e13eb9e3eca contains an initial version. Comments and additions are welcome. Since Gists do not allow PRs from others I could set up a branch for inclusion in osm-carto if you think that would be good.

Contributor

nebulon42 commented Aug 26, 2016

Maybe a tutorial document for new developers might be useful. https://gist.github.com/nebulon42/e5f73e511d44726ef66c7e13eb9e3eca contains an initial version. Comments and additions are welcome. Since Gists do not allow PRs from others I could set up a branch for inclusion in osm-carto if you think that would be good.

@Ircama

This comment has been minimized.

Show comment
Hide comment
@Ircama

Ircama Aug 27, 2016

Contributor

Incentivizing the involvement of new contributors is always an essential process for providing quality, progress, innovation and long life to an open project and any initiative towards this target I think is appropriate.

Guidelines, recommendations and documented best practices would be important to save time and concentrate all efforts on the quality of implementation, on the related testing and QA.

BTW on the installation I tried to provide something here by now: https://github.com/Ircama/switch2osm.github.io/blob/tilemill-osm-carto/tilemill-osm-carto.md
Hints related to the environment to use locally or in cloud would also be useful.

Finally, I’m afraid that this issue unfortunately references an early PR of mine as an example to blame. Indeed I did not realize of some problems there and anyway did not mean to procure any irritation.

Contributor

Ircama commented Aug 27, 2016

Incentivizing the involvement of new contributors is always an essential process for providing quality, progress, innovation and long life to an open project and any initiative towards this target I think is appropriate.

Guidelines, recommendations and documented best practices would be important to save time and concentrate all efforts on the quality of implementation, on the related testing and QA.

BTW on the installation I tried to provide something here by now: https://github.com/Ircama/switch2osm.github.io/blob/tilemill-osm-carto/tilemill-osm-carto.md
Hints related to the environment to use locally or in cloud would also be useful.

Finally, I’m afraid that this issue unfortunately references an early PR of mine as an example to blame. Indeed I did not realize of some problems there and anyway did not mean to procure any irritation.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Aug 27, 2016

Collaborator

Finally, I’m afraid that this issue unfortunately references an early PR of mine as an example to blame. Indeed I did not realize of some problems there and anyway did not mean to procure any irritation.

One of us should have stepped in and said something. Knowing what to do here relies on unwritten knowledge.

Collaborator

pnorman commented Aug 27, 2016

Finally, I’m afraid that this issue unfortunately references an early PR of mine as an example to blame. Indeed I did not realize of some problems there and anyway did not mean to procure any irritation.

One of us should have stepped in and said something. Knowing what to do here relies on unwritten knowledge.

@Ircama

This comment has been minimized.

Show comment
Hide comment
@Ircama

Ircama Aug 27, 2016

Contributor

It is generally useful to write down best practices as well as advise for improvements when a problem arises (maybe pointing to the best practice document). This especially for contributors who may join the group just for a specific purpose (and mine is to verify the feasibility to improve the rendering of mountain areas described at http://wiki.openstreetmap.org/wiki/Hiking, avoiding impacts for the current adoptions, which I think would provide great benefit to OSM).

Contributor

Ircama commented Aug 27, 2016

It is generally useful to write down best practices as well as advise for improvements when a problem arises (maybe pointing to the best practice document). This especially for contributors who may join the group just for a specific purpose (and mine is to verify the feasibility to improve the rendering of mountain areas described at http://wiki.openstreetmap.org/wiki/Hiking, avoiding impacts for the current adoptions, which I think would provide great benefit to OSM).

@dieterdreist

This comment has been minimized.

Show comment
Hide comment
@dieterdreist

dieterdreist Aug 27, 2016

2016-08-26 12:19 GMT+02:00 Paul Norman notifications@github.com:

part of it is I view this stylesheet as the one chosen to be on
tile.osm.org not the stylesheet for osm.org,

actually this is the style sheet that was developed for osm.org, for many
years, there's a straight continuity from the former mapnik stylesheet to
osm-carto: when Andy ported the xml style to carto he explicitly tried to
make it as similar as possible. On this background, this style sheet is
different to the other style sheets chosen to be on the front page, but not
rendered with osmf controlled ressources and (AFAIK) not developed for the
main osm.org page.

and part of it is that it's fairly common for OSM software projects not to
be on the openstreetmap organization. Examples include JOSM, taginfo,
cgimap, and overpass.

none of them is default on the front page and JOSM and cgimap are at least
linked/mirrored from the official repo:
https://github.com/openstreetmap?page=1
Maybe osm-carto and taginfo could also be included this way to the git repo.

Cheers,
Martin

dieterdreist commented Aug 27, 2016

2016-08-26 12:19 GMT+02:00 Paul Norman notifications@github.com:

part of it is I view this stylesheet as the one chosen to be on
tile.osm.org not the stylesheet for osm.org,

actually this is the style sheet that was developed for osm.org, for many
years, there's a straight continuity from the former mapnik stylesheet to
osm-carto: when Andy ported the xml style to carto he explicitly tried to
make it as similar as possible. On this background, this style sheet is
different to the other style sheets chosen to be on the front page, but not
rendered with osmf controlled ressources and (AFAIK) not developed for the
main osm.org page.

and part of it is that it's fairly common for OSM software projects not to
be on the openstreetmap organization. Examples include JOSM, taginfo,
cgimap, and overpass.

none of them is default on the front page and JOSM and cgimap are at least
linked/mirrored from the official repo:
https://github.com/openstreetmap?page=1
Maybe osm-carto and taginfo could also be included this way to the git repo.

Cheers,
Martin

@imagico

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico Aug 27, 2016

Collaborator

One problem with getting started is that initially you often run into problems but do not realize or misinterpret the nature of these problems due to lack of background knowledge.

A particular problem that should be communicated is the biting off more than you can chew issue. Everyone runs into this on occasion. You think about making just a small change but realize that this has a tons of side effects that require significant work to actually result in an overall improvement. There are three ways to deal with this

  • ignoring it, continuing working on what you initially planned and not looking at the problems it creates. You choose sample areas for testing that do not exhibit the problems for example.
  • backing off and accepting the problem was larger than you could handle at this time or restricting yourself to only a small part of it that can be addressed independently.
  • raising to the challenge, embracing the difficulties.

Usually newcomers do not make this choice deliberately. IMO one of the key tasks of the maintainers is to help contributors choosing the second or third approach. The desire to be friendly to newcomers will often put pressure on accepting the first option though - which then frequently leads to one problem solved but two or three additional ones created.

Regarding cartographic review - guidance from the maintainers is central to contributors knowing where they stand. A laisser-faire-approach here is not generally helpful. New contributors often bring in interesting new ideas and it is crucial to look at these with an open mind but it is also good IMO to be upfront about the fact that choices are ultimately subjective. It is important where possible to explain your reasoning for certain choices but ultimately you cannot prove something does not work design wise.

Looking back at my first contributions - one of the positive experiences was that i was able to change negative opinions on certain changes through arguments. This is both good in the way that arguments can make a difference and because bringing forward convincing arguments for your change is demanded from contributors.

Collaborator

imagico commented Aug 27, 2016

One problem with getting started is that initially you often run into problems but do not realize or misinterpret the nature of these problems due to lack of background knowledge.

A particular problem that should be communicated is the biting off more than you can chew issue. Everyone runs into this on occasion. You think about making just a small change but realize that this has a tons of side effects that require significant work to actually result in an overall improvement. There are three ways to deal with this

  • ignoring it, continuing working on what you initially planned and not looking at the problems it creates. You choose sample areas for testing that do not exhibit the problems for example.
  • backing off and accepting the problem was larger than you could handle at this time or restricting yourself to only a small part of it that can be addressed independently.
  • raising to the challenge, embracing the difficulties.

Usually newcomers do not make this choice deliberately. IMO one of the key tasks of the maintainers is to help contributors choosing the second or third approach. The desire to be friendly to newcomers will often put pressure on accepting the first option though - which then frequently leads to one problem solved but two or three additional ones created.

Regarding cartographic review - guidance from the maintainers is central to contributors knowing where they stand. A laisser-faire-approach here is not generally helpful. New contributors often bring in interesting new ideas and it is crucial to look at these with an open mind but it is also good IMO to be upfront about the fact that choices are ultimately subjective. It is important where possible to explain your reasoning for certain choices but ultimately you cannot prove something does not work design wise.

Looking back at my first contributions - one of the positive experiences was that i was able to change negative opinions on certain changes through arguments. This is both good in the way that arguments can make a difference and because bringing forward convincing arguments for your change is demanded from contributors.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Aug 29, 2016

Collaborator

actually this is the style sheet that was developed for osm.org,

I'd rather keep discussion on what this stylesheet is elsewhere - it's minimally connected with onboarding. For onboarding we already have someone interested in the style and some interest in contributing, not just commenting on issues.


Most new contributors seem to get started with adding features rather than improving cartography or other more valuable types of contributions. Is this because that's what new people are interested in, or are we filtering out those with other interests implicitly with our documentation.

Collaborator

pnorman commented Aug 29, 2016

actually this is the style sheet that was developed for osm.org,

I'd rather keep discussion on what this stylesheet is elsewhere - it's minimally connected with onboarding. For onboarding we already have someone interested in the style and some interest in contributing, not just commenting on issues.


Most new contributors seem to get started with adding features rather than improving cartography or other more valuable types of contributions. Is this because that's what new people are interested in, or are we filtering out those with other interests implicitly with our documentation.

@matthijsmelissen

This comment has been minimized.

Show comment
Hide comment
@matthijsmelissen

matthijsmelissen Aug 29, 2016

Collaborator

I can also imagine adding new features is one of the more easy things to do.

Collaborator

matthijsmelissen commented Aug 29, 2016

I can also imagine adding new features is one of the more easy things to do.

@kocio-pl

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Aug 29, 2016

Collaborator

I'm not sure if this is true in general. I started with adding shop icons and that was not that easy (although we have many examples to follow them), while changing some colors lately was dead easy from a technical point of view.

Maybe it's not about what is easy and people just care more for their favorite missing features than for optimizing what is already visible on the map? Some people have simple comments on polish forum about what could be changed (like making tertiary yellow or that cemetery in the forest should be more visible), but most of the time they don't even try to create a ticket and we don't see them here - and I don't understand why.

Collaborator

kocio-pl commented Aug 29, 2016

I'm not sure if this is true in general. I started with adding shop icons and that was not that easy (although we have many examples to follow them), while changing some colors lately was dead easy from a technical point of view.

Maybe it's not about what is easy and people just care more for their favorite missing features than for optimizing what is already visible on the map? Some people have simple comments on polish forum about what could be changed (like making tertiary yellow or that cemetery in the forest should be more visible), but most of the time they don't even try to create a ticket and we don't see them here - and I don't understand why.

@geostonemarten

This comment has been minimized.

Show comment
Hide comment
@geostonemarten

geostonemarten Aug 31, 2016

but most of the time they don't even try to create a ticket and we don't see them here - and I don't understand why.

It is simple. You need speak in english first. You need know that project. There is not bypass to signal a bug on OSM.org or other site using this stylesheet... Users or Openstreetmap contributors have a preference for their local community. If you want to add more connection it is necessary to add a refering contributor. For exemple on French, German, English. Next it's necessary to add a consensus on deferents choices (style).

There is 3 approachs for a contributor : Add missing elements, fix elements, optimise project.

For a contributor of this project you need know developpement.

note :
TileMill is no longer in active development. For our most up-to-date map design tool, check out Mapbox Studio.

geostonemarten commented Aug 31, 2016

but most of the time they don't even try to create a ticket and we don't see them here - and I don't understand why.

It is simple. You need speak in english first. You need know that project. There is not bypass to signal a bug on OSM.org or other site using this stylesheet... Users or Openstreetmap contributors have a preference for their local community. If you want to add more connection it is necessary to add a refering contributor. For exemple on French, German, English. Next it's necessary to add a consensus on deferents choices (style).

There is 3 approachs for a contributor : Add missing elements, fix elements, optimise project.

For a contributor of this project you need know developpement.

note :
TileMill is no longer in active development. For our most up-to-date map design tool, check out Mapbox Studio.

@Ircama

This comment has been minimized.

Show comment
Hide comment
@Ircama

Ircama Aug 31, 2016

Contributor

TileMill is no longer in active development. For our most up-to-date map design tool, check out Mapbox Studio.

Even if the installation of Mapbox Studio on Windows is straightforward, I could not succeed in configuring it to run openstreetmap-carto with the PostgreSQL instance already supporting TileMill (neither project.mml nor project.yaml renamed to project.yml appear to be compatible). Is there a detailed (and tested) step-by-step guide on this specific configuration?

Contributor

Ircama commented Aug 31, 2016

TileMill is no longer in active development. For our most up-to-date map design tool, check out Mapbox Studio.

Even if the installation of Mapbox Studio on Windows is straightforward, I could not succeed in configuring it to run openstreetmap-carto with the PostgreSQL instance already supporting TileMill (neither project.mml nor project.yaml renamed to project.yml appear to be compatible). Is there a detailed (and tested) step-by-step guide on this specific configuration?

@matthijsmelissen

This comment has been minimized.

Show comment
Hide comment
@matthijsmelissen

matthijsmelissen Aug 31, 2016

Collaborator

I don't think many of us run Windows.

Do you get any specific error messages?

Collaborator

matthijsmelissen commented Aug 31, 2016

I don't think many of us run Windows.

Do you get any specific error messages?

@Ircama

This comment has been minimized.

Show comment
Hide comment
@Ircama

Ircama Aug 31, 2016

Contributor

These are the steps I do:

  • Perform all steps as per already reported guide https://github.com/Ircama/switch2osm.github.io/blob/tilemill-osm-carto/tilemill-osm-carto.md and verify that TileMill works
  • Download and install Mapbox Studio Classic desktop app
  • Rename the openstreetmap-carto main folder to openstreetmap-carto.tm2
  • In openstreetmap-carto.tm2, rename project.yaml to project.yml
  • Run Mapbox Studio Classic desktop app, wait for the main window to appear, press connect, login with my Mapbox account through the desktop app, allow everything.
  • Press "Source | Create custom vector Tiles | + Blank source"
  • Press “Styles and Sources” (button at the bottom left part of the application window)
    -- Press Browse
  • Navigate to the openstreetmap-carto.tm2 and open it: I get this:

Error
Invalid tilesource protocol: nul

I am not sure these are the correct steps.
There should be a problem in project.yml (project.yaml of openstreetmap-carto) because the default (much simpler) projects created by Mapbox through default presets work.

Contributor

Ircama commented Aug 31, 2016

These are the steps I do:

  • Perform all steps as per already reported guide https://github.com/Ircama/switch2osm.github.io/blob/tilemill-osm-carto/tilemill-osm-carto.md and verify that TileMill works
  • Download and install Mapbox Studio Classic desktop app
  • Rename the openstreetmap-carto main folder to openstreetmap-carto.tm2
  • In openstreetmap-carto.tm2, rename project.yaml to project.yml
  • Run Mapbox Studio Classic desktop app, wait for the main window to appear, press connect, login with my Mapbox account through the desktop app, allow everything.
  • Press "Source | Create custom vector Tiles | + Blank source"
  • Press “Styles and Sources” (button at the bottom left part of the application window)
    -- Press Browse
  • Navigate to the openstreetmap-carto.tm2 and open it: I get this:

Error
Invalid tilesource protocol: nul

I am not sure these are the correct steps.
There should be a problem in project.yml (project.yaml of openstreetmap-carto) because the default (much simpler) projects created by Mapbox through default presets work.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Sep 1, 2016

Collaborator

I don't think many of us run Windows.

I do, but I run kosmtik on a linux machine and access it over the network.

Even if the installation of Mapbox Studio on Windows is straightforward, I could not succeed in configuring it to run openstreetmap-carto with the PostgreSQL instance already supporting TileMill (neither project.mml nor project.yaml renamed to project.yml appear to be compatible). Is there a detailed (and tested) step-by-step guide on this specific configuration?

Mapbox Studio Classic is for developing styles which use a different technology and will not work with OpenStreetMap Carto.

Collaborator

pnorman commented Sep 1, 2016

I don't think many of us run Windows.

I do, but I run kosmtik on a linux machine and access it over the network.

Even if the installation of Mapbox Studio on Windows is straightforward, I could not succeed in configuring it to run openstreetmap-carto with the PostgreSQL instance already supporting TileMill (neither project.mml nor project.yaml renamed to project.yml appear to be compatible). Is there a detailed (and tested) step-by-step guide on this specific configuration?

Mapbox Studio Classic is for developing styles which use a different technology and will not work with OpenStreetMap Carto.

@Ircama

This comment has been minimized.

Show comment
Hide comment
@Ircama

Ircama Sep 1, 2016

Contributor

I do, but I run kosmtik on a linux machine and access it over the network.

That is the way I also had to do at the end.

Mapbox Studio Classic is for developing styles which use a different technology and will not work with OpenStreetMap Carto.

Thanks a lot for this clarification. I also imagined that Mapbox Studio Classic was exploiting different formats (and Mapbox Studio should implement a vector based rendering engine, so not Mapnik).

Contributor

Ircama commented Sep 1, 2016

I do, but I run kosmtik on a linux machine and access it over the network.

That is the way I also had to do at the end.

Mapbox Studio Classic is for developing styles which use a different technology and will not work with OpenStreetMap Carto.

Thanks a lot for this clarification. I also imagined that Mapbox Studio Classic was exploiting different formats (and Mapbox Studio should implement a vector based rendering engine, so not Mapnik).

@matkoniecz

This comment has been minimized.

Show comment
Hide comment
@matkoniecz

matkoniecz Sep 4, 2017

Collaborator

https://switch2osm.org/loading-osm-data/ that I used when I first started developing for this style and wanted to reuse now appears to be outdated. It may be fixable by switch2osm/switch2osm.github.io#34

Collaborator

matkoniecz commented Sep 4, 2017

https://switch2osm.org/loading-osm-data/ that I used when I first started developing for this style and wanted to reuse now appears to be outdated. It may be fixable by switch2osm/switch2osm.github.io#34

@Ircama

This comment has been minimized.

Show comment
Hide comment
@Ircama

Ircama Sep 4, 2017

Contributor

I have collected some installation details here and occasionally I try to keep it updated by checking openstreetmap-carto documentation and recommendations (unfortunately, I cannot find time enough to answer requests of support arising there). It should anyway provide more recent and up to date information than https://switch2osm.org.

Contributor

Ircama commented Sep 4, 2017

I have collected some installation details here and occasionally I try to keep it updated by checking openstreetmap-carto documentation and recommendations (unfortunately, I cannot find time enough to answer requests of support arising there). It should anyway provide more recent and up to date information than https://switch2osm.org.

@kocio-pl

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Sep 5, 2017

Collaborator

I have recently expanded Wiki page about Standard tile layer (which is mostly about osm-carto style) and included a link to your great tutorials. We can expand this page even more and since it's not the official documentation, there can be more useful informations which are outside the scope of the project itself.

Collaborator

kocio-pl commented Sep 5, 2017

I have recently expanded Wiki page about Standard tile layer (which is mostly about osm-carto style) and included a link to your great tutorials. We can expand this page even more and since it's not the official documentation, there can be more useful informations which are outside the scope of the project itself.

@kocio-pl

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Mar 26, 2018

Collaborator

This could be helpful for onboarding: #2256.

Collaborator

kocio-pl commented Mar 26, 2018

This could be helpful for onboarding: #2256.

@kocio-pl

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Apr 27, 2018

Collaborator

I believe we're now on the right track for onboarding. We have tools (like Docker installation framework), wiki documentation explaining basic facts about the style, templates for issue and PR tickets, and we have people starting and willing to design things, discuss them and produce a code with testing. The last thing needs some more work, but I'm pretty happy with more people able to make the code after using just few links.

I hope we can make it sustainable trend. The core actions that I think made the change are:

  • communicating with people a lot (even with basic "I guess it's OK")
  • talking about osm-carto outside the repo
  • making decisions (instead of constant waiting and endless analysis)
  • merging stuff and making time based releases (so the people know that the chances are good that their work will pay off)
  • constantly asking if somebody wants to make a try

I might be wrong and the real reasons might be different, but at least it flies now.

Collaborator

kocio-pl commented Apr 27, 2018

I believe we're now on the right track for onboarding. We have tools (like Docker installation framework), wiki documentation explaining basic facts about the style, templates for issue and PR tickets, and we have people starting and willing to design things, discuss them and produce a code with testing. The last thing needs some more work, but I'm pretty happy with more people able to make the code after using just few links.

I hope we can make it sustainable trend. The core actions that I think made the change are:

  • communicating with people a lot (even with basic "I guess it's OK")
  • talking about osm-carto outside the repo
  • making decisions (instead of constant waiting and endless analysis)
  • merging stuff and making time based releases (so the people know that the chances are good that their work will pay off)
  • constantly asking if somebody wants to make a try

I might be wrong and the real reasons might be different, but at least it flies now.

@matthijsmelissen

This comment has been minimized.

Show comment
Hide comment
@matthijsmelissen

matthijsmelissen Apr 27, 2018

Collaborator

Thanks @kocio-pl for your great contributions in this respect!

Collaborator

matthijsmelissen commented Apr 27, 2018

Thanks @kocio-pl for your great contributions in this respect!

@kocio-pl

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Apr 29, 2018

Collaborator

Since at the moment onboarding looks quite healthy, I will close the ticket. Might be reopened if there will be a need to do it again.

Collaborator

kocio-pl commented Apr 29, 2018

Since at the moment onboarding looks quite healthy, I will close the ticket. Might be reopened if there will be a need to do it again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment