search

gwtproject / gwt-site

Sources of the pages of the gwtproject.org website.
150 stars 332 forks source link

add a roadmap site #353

Closed FrankHossfeld closed 7 months ago

FrankHossfeld commented 8 months ago

A roadmap provides confidence for customers of the GWT SDK.

FrankHossfeld commented 8 months ago

@niloc132 Are ther other high level goals to mention?

niloc132 commented 8 months ago

This is pretty light on actual details, but at least it does get the user looking in the right direction to see where this is tracked.

Thoughts on a github issue label or milestone to denote "this task is looking for a contributor/sponsor"? My thinking is that we could also summarize that the milestones aren't fixed, but if someone was hoping to get another feature in to a release, that would be a good starting point? I'm not familiar with how other projects handle this (outside of "Sorry, we don't take external contributions" or "If you want to work on this, ask us first, and tell us your whole plan before starting", etc).

jnehlmeier commented 8 months ago

Thoughts on a github issue label or milestone to denote "this task is looking for a contributor/sponsor"? My thinking is that we could also summarize that the milestones aren't fixed, but if someone was hoping to get another feature in to a release, that would be a good starting point? I'm not familiar with how other projects handle this (outside of "Sorry, we don't take external contributions" or "If you want to work on this, ask us first, and tell us your whole plan before starting", etc).

Kind of depends on what the 2.x branch should become? Everything that is not related to compiler, java language features and emulation would need to be done twice: once in the 2.x branch and once in the J2CL compatible library if it exists. Otherwise the upgrade path could cause trouble if bugs re-appear and such.

Usually these labels are more used to mark easy issues for new contributors. I mean every issue is looking for a contributor to solve it, so I don't see the point of marking some explicitly. But of course we could add some text to this PR to clarify that additional contributions are welcome, even if the issue is not planned in the roadmap.

I get that having a roadmap will make some people happy as it implies someone is thinking about the project. But as soon as we commit this PR someone needs to actually plan releases continuously. An empty roadmap looks bad as well. So in reality I personally would favor an automated quarterly release and what's committed in main will be released (no manual smoke testing anymore). Nobody needs to plan then but obviously no concrete roadmap would exist then as well. We could define priorities / high level goals though, possibly as milestones or projects.

FrankHossfeld commented 8 months ago

I'll added informations about donation and contributing.

FrankHossfeld commented 8 months ago

I get that having a roadmap will make some people happy as it implies someone is thinking about the project. But as soon as we commit this PR someone needs to actually plan releases continuously. An empty roadmap looks bad as well. So in reality I personally would favor an automated quarterly release and what's committed in main will be released (no manual smoke testing anymore). Nobody needs to plan then but obviously no concrete roadmap would exist then as well. We could define priorities / high level goals though, possibly as milestones or projects.

I'll like the idea of a automated quarterly releases. Also having deployed a HEAD-SNAPSHOT version would be great. (do we have that?) I have no problems using a SNAPSHOT during development. In my experience a better way than a smoking test. But that's something we should discuss anywhere else (GWT Project Discussions?)