Contributing to diffusionkinetics/open

[stites]

I was going to use this repo for some toy problems, but I'm wondering if #46 is a huge refactor that I should wait for -- does #46 make backward-incompatible changes to the API?

On a related note, if someone wants to contribute to this repository, how do development cycles and issue management work and how do end users become more aware of upcoming changes?

[glutamate]

#46 is something weird someone opened. the underlying changes are only to an added module to lucid-extras.

EDIT: just noticed this merge was going the other way, merging master into an old branch.

[glutamate]

there is currently zero project management on this repo!

[stites]

Haha, good to know. If I was looking to contribute, are there any places you would suggest looking at?

[glutamate]

@stites i will try to put up a roadmap, but a good place to start is #31 which will also make @NickSeagull happy

[stites]

Cool beans! I'll take a look (although @NickSeagull mentioned in that issue he was thinking about submitting a PR).

Perhaps after putting up a roadmap you should close this issue.

[NickSeagull]

Thinking about this all day (no jokes): Would you be open to "donating" these packages in separate repositories to dataHaskell? I think it would be useful to have them separatedly, so each of them has issues as a roadmap, and contributors could see easily what to fix.

If you dont like this, maybe making another Github organization called DiffusionKineticsOpen. I think that fragmentation of this environment you've created is important as it will attract more users, in my opinion.

Also, if you added it to the dataHaskell organization it would get even more visibility. But it's your word the one that matters 😄

About the PR @stites , I havent had the time to work on it yet, but would like to.

[glutamate]

@NickSeagull experience has just shown that developing in a monorepo is smoother for development when there are interdependencies. E.g. both Facebook and Google each have all of their code in a single git repo; in haskell, look e.g. at the yesod repo to see this working. Every large project I have worked on in the past has started as several repos and we have ended up merging them into one repo and it has been a huge win.

[NickSeagull]

Sounds great! It's a matter of designing a well drawn roadmap then. Maybe you could add labels for the issues for each project?

[glutamate]

Here is the first one: https://github.com/diffusionkinetics/open/wiki/Inliterate-roadmap

[stites]

Thanks, @glutamate! Since you are already using Github for issue management, you might want to consider converting the roadmaps to Issues and Milestones (which is just a little less overhead to maintain). I'm not about to argue that Github is good for any kind of project management, though, so take my words with a grain of salt.

Regardless, I think that closes this ticket. I'm not quite sure how you want to address the open source organizations part that was brought up (I actually thought diffusionkinetics was already an open source org and the website is down so I can't verify) -- but I think that can be addressed offline or in another issue.