Acceptance guidelines

[64kramsystem]

I think it's very important for this project to have reasonably good standards, particularly because the projects are meant to be references.

I've started to think about them, and I've divided them in two categories: low level requirements and high level guidelines.

Low level regards essentially the formal part of the project. This is pretty much ordinary stuff, and can be automated for the most part.

High level is the difficult one. I was discussing with @erlend-sh, and we were in agreement that adhering to a given library's design is crucial. Immediate mode libraries are hard to get (fundamentally) wrong, as there's little to design. Retained ones/ECS are the hard ones, but honestly, I expect there to be very few (if any) ports, since redesigning (source projects are typically immediate mode) and porting at the same time is a very demanding task.

Something I wanted to add to the high level guidelines is:

• optimizations of any kind should be avoided; not only they it increase the cognitive load, but if they're not the product of careful profiling, they will give false indications about the performance profile of a project/library (I've cough cough seen this recently 😂)
• I was thinking about making explicit, in a given port's information, if the port is exact this may not be of any use to end users; it was important for me, while developing, since I needed comparison, but I think end users won't do the same.

@AlexEne @erlend-sh Let me know what you think. Both levels are right now proposals.

I'll open the discussion about Alex's point about keeping ports up to date, since I think it's not a simple one.

[64kramsystem]

Addendum: Both Erlend and I had the idea of inviting library maintainers to perform reviews. I think Erlend actually sent the first invitation (Fedor didn't reply). If we agree on this, I'll open issues on the library repositories, so that we can discuss with the maintainers directly.

[erlend-sh]

Yeah, the involvement of library/engine maintainers is a tricky one. We want input from maintainers to ensure that the examples provided here are the best possible representation of whichever toolkit is being used. On the other hand, we don’t want to put any additional burden on maintainers.

I guess what needs to be made clear here is that there’s no expectation of maintainers to get involved with the formulation of best practices for their respective tools, but hopefully it will benefit them to do so.