Simon, agree that’s a danger. I think the starting point is not a list of technical tasks, but strategic goals that have technical implications and to which technical needs can be linked. Connect up the tech to overall purpose. For instance, the data privacy for gdpr compliance is a osmf goal. To achieve that there’s a specific implementation need. The EWG needs to look at all means to achieve it — thus far putting out a cfp (repeatedly) has not turned up any rails devs. We need to think about why, and evaluate changes of tactics.
At yesterday’s board meeting we talked about various MWG needs to connect civicrm and OSM.org. So another example. It’s not all “boring”. There’s always a swirl of ideas to refresh OSM.org landing page. Primarily that’s a communication and design question, but for ewg the question is how ready is the rails app for implementing new designs. Mikel On Friday, November 20, 2020, 6:04 AM, Simon Poole <si...@poole.ch> wrote: Without at least some guidance from the board on purpose and scope I see a real danger of this turning in to yet another iteration of "lets make a top ten list of stuff that might attract devs" with more money, aka not just GSOC, thrown in as the sole change. With the boring stuff that "actually needs to be done" (tm), being ignored. it isn't as if we don't have the experience of numerous failed EWG reboots. Examples: - the data privacy related work that needs on the API, the website and data distribution, this is probably the best defined and scoped work that has ever existed in the history of OSM, still it has made zero progress over the last three years, - putting a system in place to manage third party sources, permissions to use them and provide attribution in a scaleable fashion (realistically just providing the mechanics for this wont be enough, as the clean up itself has to be organized and that could easily require multiple man years of clerical work). I'm sure there are other similar items from operations and communications that are simply never going to make any kind of list without the EWG actually being made -responsible- for clearly defined outcomes instead of a lot of hand waving that will simply gyrate to projects that result in the largest amount of back patting (iD etc). Simon Am 19.11.2020 um 17:09 schrieb Paul Norman via dev: > The OSMF Board is looking at restarting the Engineering Working Group > with a revised scope to include handling paid software development. > This scope needs to be developed with existing and new volunteers, but > my ideas are that it would include > > - Google Summer of Code, > - managing development to be paid by the OSMF by contracts and grants, > and > - collaborating with other organizations for multi-organization grants. > > It would do this by by > - placing calls for proposals for paid work on topics like top ten tasks; > - accepting other proposals; > - defining an approximate distribution of OSMF funds for development > between primary/secondary/tertiary services, external services, and > new services; > - encouraging applications from skilled individuals who aren't > professional developers, professional contractors, companies, and others. > > Once the scope and funding distribution guidelines are defined we > would want to start with low-risk projects involving experienced > people who need less management. > > If you are interested in changing the EWG to handle these roles, > please let me know. > > > _______________________________________________ > dev mailing list > dev@openstreetmap.org > https://lists.openstreetmap.org/listinfo/dev_______________________________________________ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
_______________________________________________ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
