How to contribute

[jcornaz]

hello,

Thank you very much for providing an alternative to TornadoFX.

I prefer your library because:

• functionality is splited into modules, letting me choose what I want
• there is module dedicated to kotlin coroutines support
• this library seems to be focused on JavaFx and Kotlin only (no json parsing, DI, promises, osgi support etc.)

But I see that I'm creating the first issue in this repository. May I ask:

• Is it the right place to give feedback?
• Is there a road-map for the future of this library?
• Are PR welcome? Or maybe is it just a Toy project?
• Is there a way to contribute to the documentation?

I'm willing to try this library, to give feedback, and even help if possible.

[hanggrian]

I feel you. While I have nothing bad to say about TornadoFX, I prefer not to commit to the whole framework just to get Kotlin extensions for JavaFX.

And about your questions:

• Yes, GitHub issues is the right place to voice feedback.
• There is a roadmap, though I do not know yet where to share that information (or that others might care).
• PR is absolutely welcome, shoot me one.
• Documentation is severely needed, there are 2 ways can do this:
  • Improve JavaDoc, modify via KDoc and Dokka will do the rest.
  • Create GitHub Wiki containing project structure, user manual, and how to contribute. This is a rather large project, simple README file won't do.

Basically what I'm saying is contribution is welcome, though I'd start with smaller PRs to see if we're on the same page about where the project is going.

[jcornaz]

There is a roadmap, though I do not know yet where to share that information (or that others might care).

I would simply create a github issue. Then it can be discussed in the comments. And you can keep up-to-date the first comment of the issue, so anyone could easily have a look at what is planned. Here is an example of road-map share/discussion of another open-source project: MarkusAmshove/Kluent#75

Or you may also simply write it in the readme. Which you probably should do once you know what is going to be in the future releases, so potential user can see where the project is going when they read it.

Create GitHub Wiki containing project structure, user manual, and how to contribute. This is a rather large project, simple README file won't do.

Currently wiki is not publicly editable. Either you could make it editable (it is a git repository under the hood and you can always revert to a previous version, if something really bad happen). Or use this kind of system if you want more control: https://stackoverflow.com/a/11481887

I'd start with smaller PRs to see if we're on the same page about where the project is going.

Actually, the goal of knowing the road-map is a way for me (and any other people discovering this project) to know in which direction this project is going. Afterwards, I would anyway discuss everything in issues first.

I close this issue, considering you answered all my questions.

[hanggrian]

I would simply create a github issue. Then it can be discussed in the comments.

Sounds great, let's try that. Funny I never thought of that before.

Currently wiki is not publicly editable. Either you could make it editable (it is a git repository under the hood and you can always revert to a previous version, if something really bad happen).

In that case, create a separate module (directory) containing all the markdown (and supporting files) and push it with gradle-git-plugin. This library's GitHub Pages is also created that way.

Actually, the goal of knowing the road-map is a way for me (and any other people discovering this project) to know in which direction this project is going.

Expect one tomorrow, along with a simple contribution guideline in README.

[jcornaz]

In that case, create a separate module (directory) containing all the markdown (and supporting files) and push it with gradle-git-plugin. This library's GitHub Pages is also created that way.

I will not be able to push it with gradle-git-plugin myself as I don't have push permissions on this repo. But that's not a problem, and I don't need such permission.

So if I understand well we shall put the wiki in a docs folder of this repository? And everyone can create PR to update the documentation? And then you push it with gradle-git-plugin from time-to-time? Or do you want documentation PR to be made against the gh-pages branch?

By the way, I would recommend, for a start to simply make the github wiki publicly editable. You may change when adoption/documentation will grow. But for know it is probably the simplest option. (If you're interested TestFx chose this option and it seems to work for them so far. Anyone can fix anything in the wiki without any ceremony.

EDIT: I've seen 7f14dcf. so everything is clear now

On another topic, would you be interested by a slack channel or anything similar? It may be handy to discuss without the need to create an issue for each small question.

[hanggrian]

I just changed TestFX wiki to prove that it is in fact publicly editable. Though I believe it's not asshole-proof, I'm willing to try and see what happens. After all, TestFX is doing just fine.

We can try gitter.