Closed FrankHossfeld closed 7 months ago
@niloc132 Are ther other high level goals to mention?
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).
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.
I'll added informations about donation and contributing.
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?)
A roadmap provides confidence for customers of the GWT SDK.