CUGOS Spring Fling "alpha"

[mapsam]

The CUGOS Spring Fling is coming up in a few weeks, and DNC is a big piece to the program for the day. @powersa has us cranking on DNC for a whole afternoon with a good number of people. That means we have to make sure this thing works well - even if it's not at 100% functionality.

@alukach @thebigspoon what do you think are the most important features to finish up by then? My immediate reaction:

• prepare the menu space to take in all of the turf functions - this would be a great day to have people adding those in! Blockers: Standardize incoming geometry (handle FeatureCollections) #5, Add tooltips #40
• establish a proper pattern for adding <form> elements for these turf operations. I'm not exactly sure how we go about doing this best, but it seems important to move forward. Exists in Create view for geoprocessing input information #2 already
• Style some basemaps? Choose a basemap? Thinking of things that someone without programming experience could work on and potentially choose good basemaps for the data.
• Clear documentation for install, Update readme #47
• SUPER clear documentation on the architecture of the project (can add to wiki)
• Establish a proper workflow for people, including for ourselves to test forks properly and add tests
• what else?

I think @thebigspoon will be there to help people out, but I'm a little worried that we're not going to be in a place to have 15 (total guess) people working on this project (that's insane, right?). @powersa you mentioned this will likely split into multiple groups working on stuff. Any idea what you expect those to be?

[alukach]

I'd also be interested to hear what the plan is for the SpringFling Code Sprint? What will people be working on?

One big thing that I'd like to get done before anything else (and have been slowly working towards), is having a much stronger set of testing. I've added tests for the Menu class in #55, but to me the big one is to get an actual set of functional tests for the existing operations. Basically, each of these operations should be provided actual input and ensure that the output is as to be expected.

I assume that adding operations will be the first thing people working on the project will want to do, and it is super trivial to add Turf operations right now. It will be import to have tests to a) ensure that nobody messed up existing functionality; and b) provide a pattern for people to follow to write tests for their new functionality. I doubt that anybody will be excited to write new tests for existing features during the sprint (with maybe the exception of @foundatron 😉).

I'm kind of operating on the mindset that no new functionality should be added until a base level of testing is completed and that underlying architecture is refined. I think the architecture component is there after #53, but testing still has room.

[mapsam]

I agree, but also don't want to show up and be all, "hey we have to write tests for an application that doesn't do anything yet!" - seems not very interesting to me, personally.

I'm a bit worried about #5 blocking the turf operations right now, and might need some help on figuring out the best way forward. Mind if I work on that so we can make sure turf operations are working smoothly?

[powersa]

Thanks for getting this conversation started @svmatthews, we've got about 3 weeks before the event.

Some info about the day:

• 4 hours of project time in the afternoon
  • some time (~1.5h) to be spent introducing people to the project... vision, how does it work, what are the components, high level overview. it may make sense to break into groups for some or all of this piece so the level of discussion is appropriate
  • other time (~2h) to be spent actually working on the project. this section will definitely be split into thematic groups, with coverage for multiple experience levels. note: the key to success is having discrete, defined tasks that participants can tackle (or make progress on) within the time frame

Ideas for the groups

• build out testing. @thebigspoon is super gungho on this topic. he's an inspirational person, and can rally people to this cause
• bug fixes
• user testing... use the application, break it, document how you broke it, create a ticket
• documentation... maybe some people want to work on this
• new features?

All of those are ❓ marks. a lot of it depends on what type of stuff actually needs to get done that fits into the "discrete and defined" criteria.

what do you guys want to get out of this? what does the project need? definitely important to keep in mind that there isn't a huge amount of time either. 4 hours goes by very quickly. so the tasks should not be huge.

[mapsam]

what do you guys want to get out of this? what does the project need?

I'm mostly wrapping my head around the potential onslaught of pull requests and how to handle them all together. There's the option that we don't merge anything into master until we've given it a look-through and fixed it up, which will likely be tasked to myself and @alukach beyond the Spring Fling. I'm fine with this, FWIW, but people might be sad if they can't get things merged into the app day-of.

If we can devise the specific groups and tasks and make sure there is at least one person per group that has a solid understanding of the code base we will remove the need for some people moving between groups. I would love if @thebigspoon took on testing but haven't heard if he wants to do that or not. His understanding of the Leaflet/DNC codebase is far more in depth than my own so we'll want him leading one of the javascript-heavy groups. I bet @aaronr would be good to help out as well?

DNC Track Groups

work in progress

1. 📋 Testing - lead by @thebigspoon, requires some in depth knowledge of Javascript
2. 💪 Features - potentially led by @aaronr? and people can think about whatever features they'd like to add, but no expectations of them being pull into master without further research from @alukach and myself.
3. ✏️ Documentation & User testing - led by @svmatthews, requires the least amount of coding knowledge and can turn into "feature requests" as well as research into tools that might be useful for those requests
4. 🪲 Bug fixes / other - rogue group led by no-one, mostly for those wanting to get their hands dirty with Leaflet & DNC for the afternoon without focusing on anything in particular.

[aaronr]

I am happy to contribute in any way to this effort. I am more than happy to lead a sub-group or just participate.

I think there are two clear paths from my perspective, but I am personally not sure which would be best:

1. We can break out by "sub-system" like outlined by @svmatthews above. A testing group, a features group, etc. This would be great if there is tooling work to be done for things like testing and fundamental documentation etc.

2. We could break out more along straight "features" and let people do all of the sub-systems. I.e. we could have a group focused on adding Turf functions... but they would select a few, implement them, write the tests and documentation etc. More of an end to end approach.

With the second approach the "features" people work on do not necessarily need to be Turf related... maybe things around messaging, menus, etc but the idea is the same... the group would go end to end and implement, write tests, and document.

Personally I kind of like the second approach as it lets people see the whole workflow. Most likely in the groups people would naturally break out further into the sub-groups to divide and concur all the tasks... but it seems like it would be more rewarding to be in a group that did it all... end to end.

As far as merging the stuff... I think having a code sprint fork that we use for the sprint would maybe help. People can create branches in that fork and we merge away during the sprint. We can set it up to have a gh-pages branch just like the real thing... so people can mess with the results. In the end when everyone goes home the core team here could go look at that fork and decide what to merge/cherrypick/re-do/toss etc. Where that fork would live, what it would be called etc I am not sure. Just an idea.

Really looking forward to pushing this forward... let me know how I can help prep.

[mapsam]

Thanks, @aaronr! I like the second option, too. I'm not exactly sure how many features will be ready to implement by the time of the spring fling. Currently trying to crunch on some of the bugs that are preventing us from doing these - such as #5

Overall, the second approach is much more holistic for individuals - so let's aim for that. Do you think we should have features pre-defined for people to work on? For each group, we need to have the following skill sets/people to make sure things are moving quickly:

1. Github masters (I can see a lot of this turning into an intro to Github, which is undesirable)
2. Someone who understands the DNC/Leaflet codebase.
3. Javascripter

having a code sprint fork that we use for the sprint would maybe help

Having a code spring fork sounds great.

We can set it up to have a gh-pages branch just like the real thing... so people can mess with the results

We are already using the gh-pages branch, but things aren't really in a "working state" so it's probably fine to run our build script every once-in-a-while for testing. @alukach what do you think about this?

In the end when everyone goes home the core team here could go look at that fork and decide what to merge/cherrypick/re-do/toss etc. Where that fork would live, what it would be called etc I am not sure.

Maybe we can get @alukach on the remote end looking at PRs if he's available during the day?

[alukach]

Sounds like planning is really moving along!

From @svmatthews

... people might be sad if they can't get things merged into the app day-of.

This could be mitigated by the fact that any collaborator can deploy their fork onto their own gh-page branch with grunt deploy. They'll be able to see and admire their feature shiny new feature at http://username.github.io/drop-n-chop.

From @aaronr

I think having a code sprint fork that we use for the sprint would maybe help. People can create branches in that fork and we merge away during the sprint. We can set it up to have a gh-pages branch just like the real thing... so people can mess with the results.

I also like this idea a lot also. It would be cool for everyone to see what they collaboratively did.

Github masters (I can see a lot of this turning into an intro to Github, which is undesirable)

I almost think this would be unavoidable. There will like be a tract that would just have the bandwidth to setup git, clone the repo, install npm, build the project, run the server.

Maybe we can get @alukach on the remote end looking at PRs if he's available during the day?

Yeah, I would be happy to do this but I do kind of worry about coming across as some controlling dude from across the internet.

[alukach]

And to add to the list of requested features:

• Adding tooltips (Add tooltips #40). @svmatthews listed this above as a blocker but I think it could be a cool feature to work on in itself (I'm kind of excited to implement it myself, I'm sure at least one other person would be interested in it).
• Once ^ (Add tooltips #40) is completed, people can begin adding documentation to all the menu operations. I'm sure the less-technical people could be interest in this. Make .webm of the operations, copy some text from turf.js documentaion, format it nicely in HTML, add it to the menu creation (or however tooltips get injected).
• Saving data (Allow a way to download/save a new file #11)! This one is a big gap that we have in features. There's a bunch of stuff to do here: download, gist, download as shapefile, topojson, csv, etc.

[mapsam]

More features:

• create "forms" for intaking operation parameters (i.e. buffer by 10 meters)
• remove layers ability to remove layers #61
• create icons for all of the turf operations (this sounds awesome)

I'm thinking that for now, focusing on this application as a GUI for Turf operations is probably the best way to move forward. Once we get all of that working we can discuss how to implement more GIS-specific operations (i.e. style based on properties)

[mapsam]

I created a milestone for the Spring Fling so we can keep track of issues we'd like to work on or have ready by that time.

https://github.com/cugos/drop-n-chop/milestones/Pre-alpha%20(Spring%20Fling)

[powersa]

Track Outline

Project Intro

What is DNC? Why are we doing it?

Install the Project

Run through install as a group. Some will be able to get it up and running in real time

Break into Sub-Tracks

Group leads: Dane, Seth, Aaron, Sam, Greg

• small groups work on adding an opp and then write tests
• groups will generally work off of a single fork
• Help Station Flotilla will assist with installs or people falling behind.

[alukach]

Another:

• What's Git? What's Github? What are issues? What are pull requests? How do I collaborate with others on their projects?

A bit off topic, but surely there will be new-comers to git.

[mapsam]

Many newcomers to git, I'd imagine. We'll likely have to have a group on its own learning about how to contribute.

[mapsam]

TODO before wednesday:

• create issues for specific turf operations and outline what needs to be done to add them (so groups can take one and roll with them)
• comment the hell out of the code - @alukach said he'll start this
• prepare presentation and include "install demo" and "how to add an operation"
• get some test data for starters
• come up with graphic that depicts how this application works

[mapsam]

Okay, I've created some issues for turf functions that can be implemented without much trouble. The groups will start with bezier #81 , simplify #82 , tin #83 , and explode #84 (I've tested these and they work great).

[alukach]

Going to get going on this tonight.

[mapsam]

👍 everybody! Dropchop was a great success at the fling.