Contributing

[circuitrider]

I have a strong desire to contribute to this. Do you have a discord or slack or somewhere you can have discussions for this purpose? I'd love to help set up a development onboarding doc with you if there isn't already one.

[elvissteinjr]

There is a contributing document in the repo. It's on the simple side, maybe even not exactly legally-sound in respect to the Steam builds exception (which wasn't need yet, builds are the same on all platforms so far), but it's written in the assumption that we can all get along and talk about issues as they come up.

Desktop+ has been a solo development effort of mine for a couple of years now. While I'm open for contributions, I'm not really running this things in a way that would suit a community project (no public roadmap for example). There were no direct code contribution so far, though that doesn't mean I'm not grateful for all the other kinds of reports and support I've received over time.

I don't have Slack. I do have Discord, as in having an account. I'm not running a server for this project though. Seems like a hassle and I don't expect much activity on there if I were to make one. If development discussions came up, I'd prefer them to be public anyways. The GitHub issue tracker is good enough for this, in my opinion. Discussions are disabled on the repo since there's already a forum on Steam for anything else (SteamVR users have a Steam account, so I don't see that as a restriction).

Now that stuff aside, what would your contributing document look like? What we have right now might not be the pinnacle of contributing files, but I don't see the need of strict guidelines when there's nothing to filter from in the first place. It's all fairly casual. If someone wants to add something, they are welcome to do so. I'm also cool with it not happening. That's just the nature of niche applications on a niche platform.

[circuitrider]

I think we can improve the document by creating some onboarding information for devs. Architecture, key features and where their relevant code, calling out things that shouldn't change, anything that is unintuitive or a hack that should probably stay, anything that is not as good as you want it to be, prime places for improvement.

This could then also be the platform from which plans could be developed for future iterations, and linked to in the doc for people to gravitate toward when choosing what to contribute toward.

[circuitrider]

I'll be honest though, I do have an ulterior motive in wanting to augment the doc. Working with you to construct it would help onboard myself to contribute more effectively. Been a few years since I've worked in cpp and I don't want to cause more trouble than help.

[elvissteinjr]

I'm still not really on board with the idea to be honest. I guess it's not the best time to make this kind of write-up as the New UI branch UI rewrite (with a good bunch of new features too) is still ongoing. There are quite a few things that aren't ideal structure-wise and are an artifact how the application grew in scope over time. Stuff that I ideally want to address eventually, but has low priority over things that actually deliver value to the user. The New UI branch is in an awkward spot of being better than master in most cases, but missing some features and updated documentation (which has to wait as I still shuffle things around). Things like the Actions are gonna get a full rewrite on both ends of the app, so documenting the current state would be a waste of time.

I suppose this comes off as very dismissive, but after v3.0 releases would be a better time to tackle this stuff in my opinion.

The C++ used in this is fairly simple btw (at least how I see it). SteamVR quirks and low reliance on external dependencies (using D3D11 & Win32 directly) might not make it the most approachable though. Comment frequency is decently high, however, so I'd suggest to just try to get something done if you really want to.