Added milestones

[joakimbengtson]

I have added some milestones (probably not as they are supposed to work on github?)

They are larger "chunks" I see in future development. This is to make all aware of these thoughts and give all a chance to think and add info.

Maybe you know someone with expertise in one of the areas mentioned? or want to be one... ;)

[joakimbengtson]

I also improved the wiki-introduction, added more info about booking categories and a screen dump from the mobile interface, take a a look.

[joakimbengtson]

@javidgon @mageng @mounte Please comment if you think its a good idea to have future larger todos as milestones? For the moment you cant edit the description in the milestones?

Should comments/ideas/feedback be added as issues, or does this foul up the issue list??

[javidgon]

@joakimbengtson In my opinion milestones as "high level" goals are ok, but actual tasks regarding implementation could suit better as "issues". But as I said in the other conversation it's a matter of taste :smile:

Regarding future tasks, It'd be great if we could have first of all a roadmap (what needs to be implemented before going to the public), and what's already there working. After that, I'd recommend to have some discussion about how each of those "required features" could be implemented (technical talk), and what's the time estimation. With that information, maybe we could start thinking about having some sort of schedule (it has to be flexible enough to allow some changes though).

Finally, I'd suggest to have a very incremental approach in the development/release process, namely to have a very basic functionality on live in the very beginning and start improving it step by step. Based on my experience that's a nice way for interacting with customers, manage team expectations and improving the product at the same time.

Does it make any sense to you guys? :smiley:

[mounte]

One thing that we really need to fix is the API. We need to know what functionality goes into each API-version. When we relase the one version of the application working with API v1 then API v1 can not be changed, the next release will use API v2, note that we still need to keep v1 alive for all those who use that version. Therefor it is important that the API is well defined and small incremental changes should not affect previous versions ... in some sense we could have an API version called dev that is the latest, but in the end I think we should develop the api adhoc, we should define the behaviour and functionality of the API and then develop, test, stage and release that version. For next version we add/remove/change behaviour and functionality and then follow the same workflow.

2014/1/15 José Vidal notifications@github.com

@joakimbengtson https://github.com/joakimbengtson In my opinion milestones as "high level" goals are ok, but actual tasks regarding implementation could suit better as "issues". But as I said in the other conversation it's a matter of taste [image: :smile:]

Regarding future tasks, It'd be great if we could have first of all a roadmap (what needs to be implemented before going to the public), and what's already there working. After that, I'd recommend to have some discussion about how each of those "required features" could be implemented (technical talk), and what's the time estimation. With that information, maybe we could start thinking about having some sort of schedule (it has to be flexible enough to allow some changes though).

Finally, I'd suggest to have a very incremental approach in the development/release process, namely to have a very basic functionality on live in the very beginning and start improving it step by step. Based on my experience that's a nice way for interacting with customers, manage team expectations and improving the product at the same time.

Does it make any sense to you guys? [image: :smiley:]

— Reply to this email directly or view it on GitHubhttps://github.com/bookio/server/issues/14#issuecomment-32420861 .

[joakimbengtson]

I agree 100% with @javidgon, I will start on a roadmap so you can see what I think must be there for a 1.0 to be released.

@mounte agree with you too, but I think we should delay a (public) API 1.0 as much as possible. Initially few users will make integrations, and it will change a LOT during the first releases in my experience...

[joakimbengtson]

Now you can find a first draft of a roadmap in the docs folder https://github.com/bookio/client/blob/master/docs/roadmap.md

This is a try to define what has to be done in the first releasable version of Bookio. Enough for someone to actually use the system.