Trying a different way of developing

[IamPersistent]

As many have noted, the refactoring I that I started on my repos has resulted in the project appearing as has gone inactive. I will agree, I handled this wrong and we are looking at ways of fixing this. 

Just to explain what I have been doing, my thought was it would be helpful to remove the ecommerce specific logic out of the framework specific logic. We would have a single "core" library that would be included, using composer to any bundle that you needed the features for. It would still allow us to have defined interfaces, even when you didn't necessarily need the feature. For example, building a service for inventory, but not really interested in sales, so you wouldn't be using any cart related features, but there are some necessary dependencies between cart and product. The way it was set up it was either have everything set up without interfaces or have to load and configure CartBundle. With the new setup you won't have to do that, core is in the dependencies of bundles.

There is also a separate library for managers, which gets a little more involved than just having interfaces and gets into more specific ways of dealing with the ecommerce classes. The managers are set up in such a way that you could use the managers and core in a different framework. So if you were wanting a lighter framework for an api like Silex or maybe even something like Slim, you could use the full logic of Vespolina, w/o having to worry about the bundles.

This has been a very ambitious refactoring and very slow going at times, especially considering its been in my "spare" time. It has also put other contributors on the outside of the development. This was never my intentions and I do apologize for this unintended consequence. What I am doing here is my first step in setting this straight.

I have added a couple of branches to VespolinaCore. One is refactor, which is the work that has been done so far on the refactoring, this is the bleeding edge of where Vespolina is going. The other branch that is there, at the moment, is the pricing branch. 

The pricing is the feature I am currently work on. There was some discussion on IRC a week or so ago about pricing  so I'm in the process of creating interfaces and tests to accomplish what was discussed coupled with the current needs in the sandbox app. What I have decided to try, instead of implementing the code to make the tests pass, I've opened a ticket for the failing tests . What I'm hoping is that contributors will want to jump in and help write the code to get the tests passing. My reasoning for trying this is based on the number of times someone has said, "What can I do to help?" I've never had a good answer for this. I know that I've faced the same problem with other projects. By picking a test to write the passing code for, most programmers, at any level of skill can have the chance to contribute. Also, it makes it easier to jump in and do something, even if you have very little time to spare.

Let me know what you think of this approach. If it seems like a good idea to others, I can write some very specific docs on the process.

<aside>The other day, I watched a great video by Matthew Weier O`Phinney that inspired me to try this approach.</aside>

[liuggio]

Thanks for sharing

--
 __________________liuggio_________________________________
 
  __/|_      We reject kings, presidents and voting.
/o )   \/    We believe in rough consensus
)__ v _/\          and running code  (I.E.T.F. credo)
______________________________________________________________

[Daniel Kucharski]

Seems people do like the unit test / ticket approach.  Some contributions have already come in.