-
Notifications
You must be signed in to change notification settings - Fork 9
PSC Meeting 2023 02 17
https://web.libera.chat/?channels=#geomoose
jmkenna, klassenjs, tchaddad, theduckylittle
- Budget check-in (Eli)
- Roadmap check in (all)
- Updates on Issues (all)
- Other topics as needed (all)
Did everything get in on time? All good?
jmckenna and klassenjs both give thumbs-up on their hanging items from last month.
It's not clear that OSGeo has actually approved their budget for 2023 yet, but we assume that will happen soon.
We got asked about our roadmap, which is not particularly visible. The current wiki/web pages we have for roadmap seem out of date. We have a smattering of stuff scattered about in PSC minutes and also the Glam-and-not-so-Glam-Wishlist-items.
Sounds like we can stand up a more concrete roadmap page on the wiki. The general idea would be that the github issues/milestones are the short term roadmap. The 4.0 milestone is sort of the long term roadmap, but that starts getting fuzzy.
duck would like to move 4.0 to being more opinionated and "take over the page" a bit more. We haven't seen any particular uptake in the ability to embed geomoose in other sites. Neither from support questions on the list or any demos we've seen in the wild. So sliding back into the more-like-2.x-era and grab a bit more of the DOM to ourselves would:
- Give us more widgets to offer the user since we could prescribe how they're used together.
- Decrease load times because we can render everything in a ReactDOM context.
- Make the layout appear a bit more seamless because, for example, if we know the toolbar is enabled before loading the mapbook then we can not do a full-page redraw on load
Other things that would be good include:
- STAC integration. Have a group point to a STAC catalog that has the webmaps extension and you have drop-in federated layers.
- OGC Features API support would be cool for editing... but the bespoke implementation (pygeoapi) only does reading and querying.
- hire a graphic designer to give us a nicer skin.
Of these Features API could show up in 3.12, but STAC / dynamic catalog support would need to be a 4.0 thing
Action Item: figure out where this page should live, make it so, point to it from multiple locations
Lots of activity the last few weeks - Here is an opportunity to check-in on things:
For the upcoming 3.11 release, here is the status of the remaining open issues:
- Issue 804 may or may not get fixed for release. It's fiddly to make the decision about what to do when new data is coming but old data is there for the same service.
- Issue 794 should be reviewed as we believe this is fixed
- Issue 760 grid hover is fixed in one of theduckylittle's local branches
- Issue 754 is hereby moved to 3.12
- Issue 748 is a documentation ticket, and we have a template based on other work done
- Issue 747 has been solved, and can move from 4.0 to 3.11
- Issue 703 Is a map bug that is still being hunted down
- Issue 588 - would ideally be solved when we bring on a designer, but until then, if someone has an opinion that can be mocked up we can try to implement a shorter-term fix
- Issue 542 & Issue 772 - are both linked to WFS and need some testing (maybe @brentfraser can take a look?)
Overall this is looking pretty good as we meander towards a 3.11 release - issues 703 and 588 being the biggest items still needing solutions.
We do also have Issue 791 which is a lot of documentation work to do. tchaddad will take a stab at the re-org part of that issue, and then there will need to be a second pass on figuring out what docs to mark as out-of-date, so that things aren't too confusing...
kalssenjs wants to discuss our Git workflows. Specifically the PR squashing process. Lots of discussion with a few main takeaway points:
- it is easy to get lost in all the rebase-ing as to what has actually changed - especially w.r.t. comments in the PR thread.
- duck's workflow is: git fetch upstream main ; git rebase upstream/main ; (do stuff) ; git push
- jim on PR Squash: prefer the PR to merge - but cleaning up the commit history of the branch before the merge is good which involves rebase/squash but is more nuanced that the squash all thing the github button does
- duck is fine with us including a merge request when we merge in a PR, but we should enforce only having meaningful commits in the PRs themselves
- coke vs. pepsi
And with that we adjourned @ 11:59 pacifc time. See everyone next month!