[geomoose-psc] Milestone decisions

[Jim Klassen]

I see is that there are two competing categorizations of milestones:

1) We plan to address this issue (ticket/feature/etc.) in x.y.z version.  These are primarily used for release progress tracking. Ideally these would be all very concrete things, and ideally make the release when all the issues in the milestone are completed. This can need to get updated if there is something critical fixed that forces another release sooner, but generally, this is how I see this style of milestone working.

2) More futuristic things that are either general plans or features we want but haven't figured out how to approach and/or features where nobody has stepped up to supply either the code (or the funds for someone to write the code) to get it done.  These are hard to assign to versions because we don't know when the work will be done.  At the moment, these issues don't really fit a milestone (and I generally leave the milestone unassigned), but it would be nice to somehow track priority and/or work effort expected to be required. Maybe we need some sort of list of items we are actively seeking help with?  Maybe some of them should get some sort of code/funding drive behind them?  Otherwise, things only tend to get done when someone volunteers to do it - which isn't generally very project release schedule oriented.

"#47 feature editing" is an example of one of these.  (Most of) the underlying structure exists to support feature editing being implemented in 3.6 (or possibly even as an add-on to 3.5). The Drawing/Markup layer already does geometry editing (although likely not attribute editing), and already can upload/download features as GeoJSON and KML.  The tools should work on the other vector layer types as well (and would just need to be enabled for that layer). The real issue is uncertainty about server side software implementing OGC standard editing protocols and so not knowing what to target to "save" the changes as a general case solution.  Maybe we don't need a general solution?  If we give up on standards and roll our own, I suspect the easiest thing for GeoMoose would be for a server to accept GeoJSON over a REST style API.

So, this one isn't marked as a 4.0 milestone because it can't be done until 4.0.  The 4.0 milestone is just code for we think it is important and we might get to it sometime in the not-immediate future.  This isn't very helpful for release planning (should the release manager hold a 4.0 release hostage if it doesn't include editing, but includes a bunch of other worthy stuff?), nor is it really communicating that this is something that could be done at any time given the how it should communicate is figured out and we are looking for someone to supply code (or funds for code).

Another thing is I know Dan has some ideas for structural changes related to updating how react/redux are used that are intended to clean up some messiness in managing internal state that will likely be part of a 4.0.  And that these changes might make some of the features people want a lot easier to implement.

So, the question to me becomes how do we communicate priorities and importance of these type 2, longer range goals that don't really fit into the type 1, issue N will be in version X.Y.Z model of milestones?



On 1/26/20 3:19 PM, Dan Little wrote:
> I've tried to create milestones for logical semver versions.
>
> - If something will require breaking changes or major codebase updates, goes to milestone 4.0.0
> - New feature goes to 3.X.0
> - Bug fix / documentation fix : Goes to 3.[current].Y
>
> We may be behind on filing all of that.
>
> On Fri, Jan 17, 2020 at 3:23 PM Eli Adam <eadam at co.lincoln.or.us <mailto:eadam at co.lincoln.or.us>> wrote:
>
>     Hi all,
>
>     How do we classify milestones on issues?
>
>     https://github.com/geomoose/gm3/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+milestone%3A3.5.0
>     shows only a few things
>
>     Looking at all the open issues,
>     https://github.com/geomoose/gm3/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen
>     there are a few more.  Trying to update the legend display and
>     eventually found this, https://github.com/geomoose/gm3/issues/324
>     That probably isn't worthy of a 3.5.0 milestone but some other ones
>     might be.
>
>     Best regards, Eli
>     _______________________________________________
>     geomoose-psc mailing list
>     geomoose-psc at lists.osgeo.org <mailto:geomoose-psc at lists.osgeo.org>
>     https://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
>
> _______________________________________________
> geomoose-psc mailing list
> geomoose-psc at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geomoose-psc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geomoose-psc/attachments/20200126/2a4f71e8/attachment.html>