search

opentecture / mindmapping

Mindmapping with Three.js
https://opentecture.github.io/mindmapping
MIT License
15 stars 2 forks source link

Publish a list of Features #14

Closed afomi closed 6 years ago

afomi commented 6 years ago

User Story

As a user of Opentecture/Product Manager I want to see what Features this tool has So that I can effectively communicate the capabilities and limitations of the software to others users.

Acceptance Criteria

Given this repo exists When a user visits /FEATURES.md User can read a list of Features.

Maintenance

Developers are encouraged to update FEATURES.md when working on Pull Requests in Feature Branches. Commonly, the FEATURE will similar to a good, descriptive commit message.

afomi commented 6 years ago

for reference: #16

theo-armour commented 6 years ago

@afomi

Very often I include at least some hints about what is going in in the read me file

example: https://github.com/opentecture/mindmapping/tree/master/connect-edit

afomi commented 6 years ago

Yep. That works well.

I'd like to have a consolidated list of features as the tools develops, something to synthesize the demos and features across releases - and ideally, a bit of a roadmap with our forward thoughts.

theo-armour commented 6 years ago

@afomi

How about we start a Markdown file with a list of features?

The list could be standalone and not tied to any particular code. A house can be built out of wood or out of bricks and still satisfy the feature list. Similarly, whatever we specify should be able to be built in JavaScript, Python or whatever.

At the moment I am building little demos that gather snippets of code or whatever. One we have a spec then I should start to be able to pull all the bits together,

afomi commented 6 years ago

@theo-armour,

The referenced Pull Request https://github.com/opentecture/mindmapping/pull/16 is exactly this - a markdown file with a list of Features.

Also, thanks for the note about pulling the bits together. That helps me understand a bit more about how you're approaching the code.

Are you familiar with git-flow or the Pull Request model? Ideally, I'd like to get in a rhythm of working on distinct features, tied more-or-less to GitHub Issues. Ultimately, we'll want a flow where code is reviewed before making it into master branch - because master should (at some point) be continually shippable. Feature work is done in branches and merged in, methodically - ideally along with test coverage. This is a bit in the future. I don't want to add to much ceremony now, but rather share the flow I'm accustomed to, for shipping working software continuously.

theo-armour commented 6 years ago

@afomi oops I overlooked #16. file has been merged

Are you familiar with git-flow or the Pull Request model?

I'm highly aware but a beginner. Mostly I live in sole-operator cowboy anything-goes country. But once there's a team git-flow is essential.

The fun bits are deciding when and where to switch from one mode to the other. So, for example, if we want lots of peeps to contribute to open-standards and open-resources then they should got-flow from the get-go.

As far as the MindMapping code is going it's too early. But for the feature list, why not? If so, will you be the maintainer and merge the pull-requests?

afomi commented 6 years ago

@theo-armour - i think we'd both have commit rights, so we could both be maintainers. Getting the Pull Request pattern established early at least ensures visibility of changes.

Whether or not we want to layer-in code reviews, etc. is something we can decide as we proceed.

afomi commented 6 years ago

We're now tracking work at: