Looking for new maintainers for the project

[recastnavigation]

Looking for new maintainers for the project

[hymerman]

Hey Mikko, it's a shame that you don't have the time for Recast and Detour any more, but a positive move to pass it on to someone else to manage!

I'd be happy to take on some responsibility alongside others - I definitely don't have the time to be the sole maintainer though. Perhaps moving the project to a new organisation, with a few members (including yourself and maybe some other frequent contributors), is the best thing for it?

[grahamboree]

Hey Mikko,
Sorry you're feeling overwhelmed! I think @hymerman makes a great point that it'd best taken over by a small group of members invested in the project. I'd love to be part of this group as well.
Honestly, I'd given up on submitting PRs to Recast, seeing them sit for a year without comment. I think opening up the project will improve the project and re-energize the community around it. I'm excited for the future of Recast. 😄

[memononen]

Awesome! I was secretly hoping that you both would be willing to help :) I've got some email privately for some more folks, I'll ask them to join the discussion here too. This is long overdue, but it has been quite hard to let go of my darling.

I have created organization recastnavigation and invited you both as admins. I might add few more. I trust your judgement to add more members as you see fit,.

I have to look up how to move the repo over to the organization, and we should be set up technically. I would suggest that the first step would be to figure out simple instructions how to contribute, and I'd like to draft a code of conduct too.

I have a couple of unfinished ends with Recast, and I'd like to discuss them at some point.

[memononen]

Repo is now moved to under the organization. I probably should give you keys to the google group, it is still quite actively used.

For contribution, I'd suggest something along the lines of https://github.com/facebook/react/blob/master/CONTRIBUTING.md
along with code of conduct based on the template by todo group .

[rwindegger]

Hey everybody,

I'm one of the private enquieries Mikko was talking about. It's good to see some movement for recast&detour. I did some work on a fork and willing to port the stuff in a more structured manner than it happened. I'm able to take over a part of the maintenance as well. And happy to join my forces with all of you.

Bye Rene

[hymerman]

Hi Graham and Rene! This is going to be good :)

Mikko - agreed, a 'Contributing' doc and Code of Conduct are needed. I'll have a look at those - the todo group one looks good.

I think we also need a Contributor License Agreement - having been on the other side of the fence I know the legal protection is more than superficial! Either CLAHub (https://www.clahub.com/) or CLA assistant (https://cla-assistant.io/) look like good options to get this done easily.

Next I'd love to get Continuous Integration set up - I've actually already got a pull request open for this :) (#89). I see you've got a really nice AppVeyor setup in your fork, @rwindegger - let's get that merged in if it's easy to separate from the other things merged into your fork, and we'll use my Travis setup. I updated to premake5, and I see you've updated the way lots of dependencies work with submodules, which is also cool.

One more thing, I've just bought recastnavigation.com just in case we want to do something with it - perhaps to host documentation, or just for project-specific email. So nobody freak out if you notice it's not available :)

[jswigart]

This is nice to see. I have a number of modifications to my own recast I wouldn't mind contributing back.

One of them that might be worth deeper discussion is something I brought up a while back in another thread(I'd have to dig it up for the historical context), but it is essentially that within my own usages of recast/detour in several of my own projects, I've converted the area and flags fields of poly areas to use a single 64 bit bitmask flags field. I feel strongly that this is far more useful than the separate area type and mask functionality that exists in the core recast, as it allows you to track different area types in an additive manner through the rasterization steps to the final result. The current mechanism of having a single area type loses a lot of contextual information about areas that stack. This mechanism opens up a range of additional uses for area type markup than what is possible in the existing library.

Perhaps we can discuss the merits of this contribution and whether or not you all feel like it would be a good thing to bring into the official fold? Thanks

[jakobbotsch]

Indeed it is nice to see more action in this repo. I have also been using Recast & Detour for many years now (in the same company as @rwindegger), so if you need more people, I would love to be a part of the maintainers.
I also have a few possible improvements that I have discussed with Mikko over email. However I have refrained from making them yet as Mikko had some good ideas and I wasn't sure exactly how to put them into effect. This is for implementation of off-mesh connections to non-adjacent tiles and for edge normals returned by findWallDistance (relates to #120).

[hymerman]

I've been having thoughts about that too @jswigart; in old projects I've done the same as you, and eventually ended up using a separate data structure to store more information on polys. And of course, this extra data is only useful if queries can use it, so another important thing to figure out is how to support custom cost functions etc. - when I've done this before I've modified dtQueryFilter but it'd be nice to allow this with only client code changes. Something to talk about soon, for sure!

[jswigart]

Perhaps we should spin off focused issue threads on specific topics for discussion?

[delscorcho]

If you need more hands, I'd be happy to help out here and there. @billassault

[rwindegger]

The CI should be easy to port over, I've uploaded VS Solutions to the repo, I should have adjusted the premake file.

Most of the Submodule stuff I did is for the dependencies of the Demo. The rendering of the UI was completly adjusted to use https://github.com/ocornut/imgui. I've updated to SDL2 instead of SDL. And did a gh-pages push for the doxygen documentation. FastLZ is pulled in from https://github.com/ariya/FastLZ and stb is pulled in from https://github.com/nothings/stb.

All in all the Demo changes will be a fast port too. Just need to do it a little more structured than i did it in the first place.

@JanielS it's good to see you here too 👍

[dougbinks]

I had a discussion with @memononen about the CLAs @hymerman recommended: https://twitter.com/dougbinks/status/674544666264539136, and he asked me to post my points here.

Basically most CLAs are complex enough to require a lawyer to understand the implications, in particular whether there is any potential liability exposure for the contributor. These issues tend to be more complex than they appear. For example guaranteeing that something is your original creation means you could be exposed to liability if someone later claims your code is a copy of theirs; litigation defence in some regions is extremely expensive.

In my view Apache 2.0 covers the main issue many companies have - a guarantee that a contributor won't sue for patent infringement for use of their contribution. This seems reasonable and fair, and doesn't expose the contributor to needing to guarantee that they own the patent rights nor infringe others. Going Apache 2.0 would need all prior contributors to agree, or a dual license. But then adding a CLA won't protect the current code either without getting all prior contributors to sign.

Note that I'm not a lawyer, but that's the real problem here - putting a legal barrier in place really requires people to have or be one.

[hymerman]

@jswigart is right, we should spin off separate issues for points raised here, let's leave this issue for people offering help for now!

I've just created one for the CLA here: #125, and one for CI here: #126. The flags/area ID chat is going on here: #81.

[grahamboree]

Awesome. You read my mind, Ben. :) Should we close this out now?

[memononen]

@hymerman @grahamboree You have now owner access to the google group.

[hymerman]

@memononen - has anyone else gotten back to you about joining?

[memononen]

@hymerman - nope, there has not been any further leads. I've pointed all even mildly interested parties to this thread.

[jakobbotsch]

There have been a few more people in this thread who have expressed interest (myself included).
But if you want to keep the list of maintainers low-size I completely understand - everyone can always make PRs anyway!

[hymerman]

I think a couple more maintainers would be a good idea. @rwindegger sorry, I didn't notice you said you'd like to join - I've just invited you. @jswigart it sounds like you'd like to contribute, which you can continue doing with pull requests - would you also like to join the org though? And @JanielS I'll invite you too.

That should be plenty of cover even if several of us are busy at once. I'll close this now but if there's anyone else that would like to be involved as more than a contributor via pull requests, leave another comment and we'll see it.

[jakobbotsch]

@hymerman Thanks for the invitation.

[delscorcho]

I'm also interested if you need more folks.

[leif81]

This is great to see the project come to life again. I have one suggestion for the new maintainers. Perhaps it'd be good to keep @memononen as one of the members of the recastnavigation GitHub group. For other outsiders who may not be following the switch of maintainership they may see this new group as fork if they don't see Mikko's name still associated, even if it's just symbolic gesture. Two cents.

[hymerman]

Mikko is still in the group, he just doesn't appear that way publicly :) (sorry for blowing your cover) @memononen could you set your group membership to public? It's on the 'people' tab of the org's settings.

[memononen]

@hymerman done, noobie mistake :)