weekly-discussion-14-12-2010.irc.log

**** DÉBUT DU JOURNAL À Tue Dec 14 19:42:03 2010

déc. 14 19:42:25 <inspiran>	in typical e-commerce software (and which probably most php'ers would do) is just say 'just update the sales order'
déc. 14 19:42:59 <inspiran>	but in lots of business cases, actually in almost all europe companies due to legal constraints, you can not do that
déc. 14 19:43:18 <inspiran>	(you are modifying a sales order / invoice which was already sent)
déc. 14 19:43:27 <inspiran>	so what do you need to do?
déc. 14 19:43:44 <inspiran>	you need to cancel the old sales order and create a new one
déc. 14 19:44:13 <inspiran>	(which involves updating the accounting balances twice)
déc. 14 19:44:57 <florian__>	yes, I already had to face this kind of problesm
déc. 14 19:45:14 <inspiran>	yeah? i am interesting to hear about how you dealt with it
déc. 14 19:46:34 <florian__>	it's part of a dev specific app developed for a client
déc. 14 19:46:54 <florian__>	but you maybe want to continue
déc. 14 19:47:16 <florian__>	sorry to cut the conv
déc. 14 19:47:25 <inspiran>	no it's ok, we need to share thoughts florian_
déc. 14 19:47:38 <florian__>	yes we're here for this
déc. 14 19:47:41 <iampersistent>	yeah, this is good :)
déc. 14 19:47:47 <florian__>	but it's not easy to keep focues
déc. 14 19:47:52 <florian__>	focused*
déc. 14 19:48:02 <inspiran>	for me it's important that before we even go think about a technical design, we first understand order processes in detail
déc. 14 19:48:13 <florian__>	yes you're right
déc. 14 19:48:46 <inspiran>	this is: understanding various situations, various deviations and have some of a common way of doing things
déc. 14 19:49:14 <florian__>	so, indeed we have to think the billing process flexible enough to permit accounting balances for example
déc. 14 19:49:37 <inspiran>	true, but that doesn't mean that we need to develop everything, some goods hooks will suffice
déc. 14 19:49:45 <inspiran>	i mean, we can't just recreate a full SAP / ERP solutions
déc. 14 19:49:48 <inspiran>	that's not the goal
déc. 14 19:50:00 <inspiran>	the goal is having which is very scalable in terms of development
déc. 14 19:50:00 <florian__>	yes see what you mean
déc. 14 19:50:17 <iampersistent>	I'm with inspiran on that, a solid interface for now, build it simple, but we have the ability to expand it in the future to specific needs
déc. 14 19:50:25 <inspiran>	yes
déc. 14 19:50:37 <florian__>	much than that, we *have* to think the billing process to handle differnet kind of impl
déc. 14 19:50:38 <inspiran>	and sf2 is ideal for it
déc. 14 19:50:54 <florian__>	yes i think so
déc. 14 19:51:01 <inspiran>	another example: 'goods movement processes'
déc. 14 19:51:26 <inspiran>	(and after that i'll eat some cheese, i'm hungry)
déc. 14 19:51:33 <florian__>	lol
déc. 14 19:51:38 <florian__>	mee too
déc. 14 19:51:40 <inspiran>	usually if you a products, you want to know where they are
déc. 14 19:51:45 <inspiran>	*have
déc. 14 19:51:56 <inspiran>	there are various possibilities
déc. 14 19:52:04 <inspiran>	a)you have them all in your kitchen
déc. 14 19:52:13 <inspiran>	b)you still need to steal it
déc. 14 19:52:41 <inspiran>	c)you don't have anything, you just buy it at your supplier when a customer orders
déc. 14 19:53:00 <inspiran>	suppose you have your products
déc. 14 19:53:19 <inspiran>	then you want to know which products you have
déc. 14 19:53:34 <inspiran>	you'll probably use an unique identification to identify your products
déc. 14 19:53:53 <inspiran>	at some point, you need to order your products with your supplier/vendor
déc. 14 19:53:59 <inspiran>	what reference will you use?
déc. 14 19:54:28 <inspiran>	you could say: i'll use the unique reference the vendor gives me
déc. 14 19:54:54 <inspiran>	but that's dumb because it often happens that you purchase the same goods from multiple vendors
déc. 14 19:55:20 <inspiran>	so ok: you create your own unique product codes, maybe very fancy with barcodes
déc. 14 19:55:36 <inspiran>	this means that for a given product, you'll need to maintaing multiple things
déc. 14 19:55:41 <inspiran>	-g
déc. 14 19:56:07 <inspiran>	1) for supplier X, 'wonderbra cup B' has  supplier id 'WOND-B-1'
déc. 14 19:56:27 <inspiran>	2)for supplier Y, 'wonderbra cup B' has supplier id '12809298309'
déc. 14 19:56:38 <florian__>	yeah see what you meen
déc. 14 19:56:48 <inspiran>	even more, the relationship with your supplier is _extremely_ important
déc. 14 19:57:28 <inspiran>	espescially for e-commerces: most e-commerce businesses i see start just with one or two main suppliers
déc. 14 19:57:35 <inspiran>	(because they get higher discounts)
déc. 14 19:57:51 <inspiran>	This also means that you actually have to maintain more information than you think
déc. 14 19:57:57 <inspiran>	a)general product information
déc. 14 19:58:14 <inspiran>	b)product information related to each of your suppliers
déc. 14 19:58:20 <inspiran>	think about discounts
déc. 14 19:58:46 <inspiran>	or 'if I buy 100 units of wonderbra, i get a 20% discount with supplier Z'
déc. 14 19:59:15 <inspiran>	you could probably even already incorporate this in your product price which you show on your site
déc. 14 19:59:49 <inspiran>	for instance, some vendors give at christmas special discounts on specific brands
déc. 14 20:00:06 <inspiran>	this information has to go *somewhere*
déc. 14 20:00:33 <inspiran>	and then there is an even nicer one:
déc. 14 20:00:38 <inspiran>	it's called consignment stock
déc. 14 20:01:25 <inspiran>	basicly, you have in your kitchen already 100 products from your vendor, but it's not in any of your financial statings, so it's technically not yours
déc. 14 20:01:40 <inspiran>	you could say you stole it b)
déc. 14 20:01:44 <inspiran>	but how does it works:
déc. 14 20:02:12 <inspiran>	you sell 25 products and and the end of the month you communicate to your vendor that you have sold 25 products
déc. 14 20:02:24 <inspiran>	now the vendor will send you an invoice for those 25 products
déc. 14 20:02:36 <inspiran>	now where are you going to store this information?
déc. 14 20:03:08 <inspiran>	it's product level information, and you typically would think of having a column 'stock_quantity' but that's bullshit
déc. 14 20:03:46 <inspiran>	in simple e-commerce sites this works fine, but at some point you just one to know more information
déc. 14 20:03:54 <inspiran>	(which involves hacking a lot)
déc. 14 20:04:48 <inspiran>	a typical consignment stock example: if you buy a newspaper, technically the store from which you have bought it, is not the owner
déc. 14 20:05:15 <inspiran>	he just sends the ones he didn't want back, and he is billed for the once he sold
déc. 14 20:05:26 <inspiran>	he just sends the ones back he didn't want back, and he is billed for the once he sold
déc. 14 20:05:33 <inspiran>	hmm, ignore last sentence :)
déc. 14 20:05:56 <florian__>	:)
déc. 14 20:06:12 <inspiran>	from a technical point of view: yes, you can have one field for stock quantity, but you need hooks to have *more* information
déc. 14 20:06:39 <inspiran>	to finish the story about goods movement
déc. 14 20:06:53 <inspiran>	suppose you want sell drugs onlnie
déc. 14 20:06:54 <inspiran>	online
déc. 14 20:07:09 <inspiran>	(medicins)
déc. 14 20:07:37 <inspiran>	warehouse management is *x-tremely* important
déc. 14 20:07:43 <inspiran>	let me explain:
déc. 14 20:08:05 <inspiran>	for starters, you need to know in which locations each medicin is
déc. 14 20:08:45 <inspiran>	and if you move this medicin from one to another warehouse, you are obligied from the government to have an audit trail
déc. 14 20:09:10 <inspiran>	This audit trail contains *all* information who the person was who moved the products
déc. 14 20:09:14 <inspiran>	who authorized this, and so on
déc. 14 20:09:37 <inspiran>	Let's come back to our stock quantity to explain me the relationship
déc. 14 20:10:10 <inspiran>	so if you would allow more detail on your inventory, you could say, i'll have a table containing:
déc. 14 20:10:18 <inspiran>	warehouse1: product3: 14 units
déc. 14 20:10:25 <inspiran>	warehouse: product3: 11 units
déc. 14 20:10:42 <inspiran>	now, you could create an user interface which allows the user to update the units
déc. 14 20:11:18 <inspiran>	but in this case for medicins, you would really to *somewhere* store in a table who 'moved' it, so who  changed the quanties
déc. 14 20:11:24 <inspiran>	quantities
déc. 14 20:11:42 <inspiran>	(i think this could be easily done with the event dispatcher)
déc. 14 20:11:58 <florian__>	yes
déc. 14 20:12:21 <inspiran>	but just wanting to show you how people often overlook things which eventually they need to hack
déc. 14 20:12:37 <inspiran>	A good example is Magento, developed by Zend members
déc. 14 20:13:04 <inspiran>	great technical guys, but their product is just a mess because all these situations were not taken into account early enough
déc. 14 20:13:17 <florian__>	that's true
déc. 14 20:13:40 <inspiran>	i mean, it's very simple to see what they have forgotten: see the plugins
déc. 14 20:14:10 <florian__>	yes
déc. 14 20:14:40 <inspiran>	but one the thing i've learned so far: don't hate business logic
déc. 14 20:14:48 <inspiran>	they can be *very* craz
déc. 14 20:14:49 <inspiran>	y
déc. 14 20:15:04 <florian__>	but plugins shouldn't be a way to let userland devs to customize easily a flexible core solution?
déc. 14 20:15:34 <inspiran>	honestly, they should be allowed to do it, even the core will faill at some times
déc. 14 20:15:49 <inspiran>	i mean, the dependency injection is  great way
déc. 14 20:15:55 <inspiran>	i mean, the dependency injection is  great way to do so
déc. 14 20:15:57 <florian__>	yes
déc. 14 20:16:03 <inspiran>	i just started some prototyping
déc. 14 20:16:56 <inspiran>	on my first sf2 project
déc. 14 20:17:09 <inspiran>	https://github.com/inspiran/AssetBookingBundle
déc. 14 20:17:20 <florian__>	cool
déc. 14 20:17:39 <inspiran>	on which i am trying to figure out how my way of thinking could be applied for more generic processes
déc. 14 20:18:24 <inspiran>	it's a simple case: my customer wants a simple reservation system to book a holiday villa they own
déc. 14 20:18:33 <inspiran>	so the process is pretty simple:
déc. 14 20:19:05 <inspiran>	customer books villa -> customer pays -> villa is booked and unavailable for the requested period
déc. 14 20:19:22 <inspiran>	(it's modeled by the Booking entity)
déc. 14 20:19:41 <inspiran>	but i realize that the process can be different if you work with third party agents / booking sites
déc. 14 20:20:26 <inspiran>	customer books villa at third party site -> third party sends booking confirmation -> payment is done at end of the month by the 3th party
déc. 14 20:21:21 <inspiran>	so what i have done is introduced a 'business object profile' which can hold information for both scenarios (or others which i don't know of yet)
déc. 14 20:21:47 <iampersistent>	if I can interject here briefly
déc. 14 20:21:52 <inspiran>	sure
déc. 14 20:22:22 <iampersistent>	I think that this project is a great example of a product and order flow that is outside of what most people thing about for ecommerce
déc. 14 20:23:00 <iampersistent>	so this is coming back to what you are working on florian__ with the product/product mgr
déc. 14 20:23:03 <florian__>	totally agree
déc. 14 20:23:34 <florian__>	kind of the same problem you described before with multiple vendors
déc. 14 20:23:43 <iampersistent>	how do we make the interface uniform enough to work within any order flow, but be inclusive enough to handle something like a reservation system
déc. 14 20:24:08 <florian__>	great example
déc. 14 20:24:47 <iampersistent>	I could easily envision a site for a spa that sells reservations for a treatment, but also sell products and maybe sell mp3s of relaxing music, all in the same site
déc. 14 20:25:13 <iampersistent>	having that level of flexiblity that you can fully implement all of those things, would be great
déc. 14 20:25:22 <inspiran>	indee
déc. 14 20:25:23 <inspiran>	d
déc. 14 20:25:31 <iampersistent>	right now its like you sell the items but they are all managed in different places and in different ways
déc. 14 20:25:47 <inspiran>	yep
déc. 14 20:26:11 <inspiran>	basicly from a conceptual point of view you only have two things: products and services
déc. 14 20:26:19 <iampersistent>	so right now, I'm not 100% how to make sure the interface can handle all of this, but I think as long as we are keeping it in mind, we'll figure out a way
déc. 14 20:26:31 <iampersistent>	right, but products can be a lot of different things
déc. 14 20:26:41 <inspiran>	i predict that the product interface will be different from services
déc. 14 20:27:08 <inspiran>	because for service the notion of 'periods' is more important than goods
déc. 14 20:27:13 <iampersistent>	right, but I feel like we need some commonality so that a product and service can be processed in a similar way
déc. 14 20:27:26 <florian__>	do services can handle all the logic by htemselves?
déc. 14 20:27:30 <iampersistent>	yeah, well and I'm also thinking about selling subscriptions
déc. 14 20:27:51 <iampersistent>	florian__ I think so, I think the product/service has to be resposible to know how to handle itself
déc. 14 20:28:04 <iampersistent>	including fulfillment
déc. 14 20:28:30 <iampersistent>	but communicate back when a product has been fulfilled, in what ever form that is
déc. 14 20:28:57 <inspiran>	hmm, but what if your products needs a third party to be fulfilled?
déc. 14 20:29:13 <iampersistent>	with a digital download, you could just add it to a dashboard for the user or push it out as a file
déc. 14 20:29:34 <iampersistent>	a physical product would need to be picked and shipped before it is considered fulfilled
déc. 14 20:29:46 <inspiran>	eg. 'fix my door' service is only forfilled when the door is really fixed
déc. 14 20:30:01 <inspiran>	*fulffilled
déc. 14 20:30:19 <inspiran>	then you need some kind of a call back
déc. 14 20:30:44 <iampersistent>	right, so in that case, when the order is placed, it goes into a queue of tasks that need to be assign to a serviceman, its assign, manually or just as tasks comes off
déc. 14 20:30:53 <inspiran>	hmm,  the product could listen to an event 'service_delivered_correctly'
déc. 14 20:31:02 <florian__>	should we apply this kind of -*/service- pattern to thoses differents processes ?
déc. 14 20:31:23 <iampersistent>	when the serviceman has finished fixing the door, he would go into the system, mark the project completed, add an notes needs for the future
déc. 14 20:31:29 <florian__>	and separate fulfillment from others
déc. 14 20:31:31 <iampersistent>	signally that it has been fulfilled
déc. 14 20:32:02 <inspiran>	ok, then we'll need some kind of a background task
déc. 14 20:32:10 <inspiran>	fine enough :)
déc. 14 20:32:33 <iampersistent>	I think before an "order" can be completed, everything has to be fulfilled, what ever that means for the specific product
déc. 14 20:33:01 <inspiran>	hmm, i'm not sure about that assumption
déc. 14 20:33:03 <iampersistent>	in my spa example, the order is finished when the mp3 has been pushed out, the product has been picked and shipped and the treatment is over
déc. 14 20:33:20 <iampersistent>	how so inspiran?
déc. 14 20:33:29 <inspiran>	i'm still thinking about an example
déc. 14 20:33:36 <iampersistent>	k
déc. 14 20:33:40 <inspiran>	something where you order, pay and then get your goods later on
déc. 14 20:33:57 <inspiran>	ah, the Groupon is maybe such a case
déc. 14 20:34:04 <iampersistent>	a think a subscription would fall into this category
déc. 14 20:34:21 <inspiran>	i mean, there is currently a hype about 'internet best offer of the day'
déc. 14 20:34:31 <inspiran>	which illustrates perfectly:
déc. 14 20:34:56 <inspiran>	my girlfriend orders something from vente-exclusive.com
déc. 14 20:34:59 <iampersistent>	if you subscribe to basecamp, the order would never be "complete" until you canceled the service
déc. 14 20:35:21 <inspiran>	she first orders, then pays, then the goods are gathered from a 3th party supplier which it ships
déc. 14 20:35:31 <inspiran>	(the process takes up to three weeks)
déc. 14 20:36:22 <iampersistent>	there are several points where you could call the order "complete" depending on your business process
déc. 14 20:36:46 <inspiran>	true
déc. 14 20:37:08 <iampersistent>	you could say the order is complete (from vente-exclusive's perspective) when you tell the 3rd party what to ship and pay them their share of the money collected
déc. 14 20:37:27 <inspiran>	(taken the example of my status management profile prototype, this would mean that in the status schema you specify for a given status whether or not it is from that point fullfilled)
déc. 14 20:37:37 <iampersistent>	or in the same case, you could require the 3rd party to signal back to you that it has been picked and shipped before it is "complete"
déc. 14 20:38:05 <iampersistent>	which is why I think ultimately, we'll have to look at an order workflow system with a similar design to what you are doing on your booking bundle
déc. 14 20:38:21 <inspiran>	yeah
déc. 14 20:38:54 <inspiran>	using the status management process you could even have two very similar processes but with different fullfillments
déc. 14 20:39:15 <iampersistent>	so how do we translate all of these ideas into interfaces? :)
déc. 14 20:39:45 <florian__>	very interesting
déc. 14 20:39:46 <inspiran>	i will take the example of 3 suisses, which is a kind of a book from which my girlfriend often orders
déc. 14 20:40:15 <inspiran>	she orders, she gets the products, and pays 3 weeks after she received the goods
déc. 14 20:40:40 <inspiran>	but some customers can't do this because their level of credebility is low
déc. 14 20:40:54 <inspiran>	so they need to first pay before the order is shipped
déc. 14 20:42:09 <inspiran>	and if they pay on time, they are allowed to pay after delivery
déc. 14 20:43:02 <florian__>	didn't know this process, but it show how much the system has to be flexible
déc. 14 20:43:55 <iampersistent>	florian__ agreed, to make it useful across many projects, we really have to look the flexiblity
déc. 14 20:44:08 <florian__>	so if we resume,
déc. 14 20:44:10 <iampersistent>	I think this is the flaw in most OS ecommerce software
déc. 14 20:45:04 <florian__>	we have fulfillment, order status and product meta information which need to be flexible
déc. 14 20:45:41 <iampersistent>	yes and payment also, based on the different scenarios that insprian has laid out
déc. 14 20:46:25 <inspiran>	we should, base on our current discussion, go back to previous scenarios which you have crossed and think about these
déc. 14 20:46:41 <inspiran>	just think about daily activities
déc. 14 20:46:44 <florian__>	we could use the pattern showed in your prototype to handle these different kinds of processes
déc. 14 20:47:08 <inspiran>	eg. suppose your local bakery would want to sell bread online, how would he do it
déc. 14 20:47:13 <florian__>	yes u're right
déc. 14 20:47:46 <inspiran>	you'll quickly discover two target audiences 1) people and 2)companies
déc. 14 20:48:02 <inspiran>	people need to pay directly, companies can pay at the end of the month
déc. 14 20:48:59 <inspiran>	i everybody of us thinks about these procesess before elaborating on a technical design, i think the solution would be much better
déc. 14 20:49:42 <florian__>	i agree
déc. 14 20:50:38 <inspiran>	maybe each could start with writing down any scenario you could think of and have them on a wiki by next week?
déc. 14 20:51:16 <inspiran>	or by mail
déc. 14 20:51:42 <florian__>	that's the first point we should have done: writing some use cases :)
déc. 14 20:52:03 <inspiran>	then, we could come up with some common concepts we need
déc. 14 20:52:47 <inspiran>	and test them against our scenarios
déc. 14 20:53:10 <inspiran>	but be awere: i do not believe that all scenarios can fit perfectly, often additional developments are needed
déc. 14 20:53:34 <iampersistent>	I think these should go up on the wiki
déc. 14 20:53:48 <florian__>	yes
déc. 14 20:53:49 <iampersistent>	I think the more information that is available, the greater the chances of getting others invovled
déc. 14 20:55:09 <inspiran>	it would even be better if we could talk to people doing the actual business
déc. 14 20:55:21 <inspiran>	i have contacts in retail but non in real estate
déc. 14 20:55:35 <inspiran>	i think real estate is also a very interesting one to look at
déc. 14 20:55:40 <iampersistent>	I know someone in real estate, I'll shoot her an email
déc. 14 20:55:58 <inspiran>	because in real estate, there normally no payment
déc. 14 20:56:03 <inspiran>	not online
déc. 14 20:56:18 <florian__>	great idea
déc. 14 20:56:43 <inspiran>	but i can assume you want to track your sales , so the administration would fill them in manually
déc. 14 20:56:57 <iampersistent>	right
déc. 14 20:58:24 <iampersistent>	well, lets start putting some use cases up on the wiki, at least get something started
déc. 14 20:58:37 <iampersistent>	the great thing about a wiki is we can expand on each others ideas
déc. 14 20:58:59 <inspiran>	where would the wiki be?
déc. 14 20:59:20 <iampersistent>	well, right now we could do it on the Symfony2-e-commerce-bundle github account
déc. 14 20:59:27 <florian__>	you mean in what place?
déc. 14 20:59:44 <iampersistent>	I think alecs said something about maybe using the resources already set up for sfShop
déc. 14 20:59:53 <florian__>	yes I thought to https://github.com/docteurklein/Symfony2-e-commerce/wiki
déc. 14 21:00:18 <iampersistent>	florian__ I agree this is the best solution for right now
déc. 14 21:00:21 <inspiran>	github is fine by for me
déc. 14 21:00:41 <inspiran>	also guys, don't forget something
déc. 14 21:00:51 <iampersistent>	by using github we increase the chance of getting community feedback
déc. 14 21:01:11 <florian__>	the wiki itself is very flexible, you can even have a git access to it https://github.com/docteurklein/Symfony2-e-commerce/wiki/_access
déc. 14 21:01:39 <inspiran>	lots of business are stores which think they need e-commerce because "everybody does it"
déc. 14 21:02:16 <iampersistent>	do we need a section about helping the customer understand what they REALLY need? ;)
déc. 14 21:02:17 <inspiran>	so often there is an interface needed to legacy systems or a way to allow them to enter orders
déc. 14 21:02:28 <inspiran>	manually
déc. 14 21:02:35 <iampersistent>	right
déc. 14 21:02:46 <inspiran>	the manual process should be more flexible than others
déc. 14 21:03:10 <inspiran>	eg, when you enter the order, the system threats it already as fulfille
déc. 14 21:03:12 <inspiran>	d
déc. 14 21:03:28 <inspiran>	they only enter it manually for a reference and reporting purposes
déc. 14 21:03:49 <inspiran>	but they should be differently saved
déc. 14 21:04:30 <inspiran>	for instance, the sales order entity should have a column allowing to differentiate between the manual and normal order
déc. 14 21:04:42 <inspiran>	so in their reporting they can easily differentiate
déc. 14 21:06:12 <inspiran>	eg. in the administration console, there is no point of being able to select the status 'waiting for customer payment'
déc. 14 21:06:27 <inspiran>	if you know it's already paid
déc. 14 21:08:30 <iampersistent>	true
déc. 14 21:08:45 <inspiran>	(ps, we need also a sexy name for the project)
déc. 14 21:08:58 <iampersistent>	how about sexy ecommerce ;)
déc. 14 21:09:17 <florian__>	sexy-commerce
déc. 14 21:09:34 <iampersistent>	actually, thats pretty cool
déc. 14 21:09:54 <inspiran>	hmm, would prefer something more abstract
déc. 14 21:10:04 <florian__>	actullay didn't tought to a name
déc. 14 21:10:05 <iampersistent>	not sure if that would confuse people or not
déc. 14 21:10:09 <inspiran>	eg. magento is nice sounding
déc. 14 21:10:11 <florian__>	idem
déc. 14 21:10:24 <iampersistent>	someone might think its a system to build porn sites :p
déc. 14 21:10:29 <florian__>	first proposition was for fun :)
déc. 14 21:10:50 <inspiran>	anybody wanting to investigate the porn scenarios and how to perform fullfillment?
déc. 14 21:10:56 <florian__>	héhé, yes too much ambiguous
déc. 14 21:10:59 <iampersistent>	lol
déc. 14 21:11:17 <florian__>	there are a lot of scenarios in there :)
déc. 14 21:11:26 <iampersistent>	I think a cool name will help
déc. 14 21:11:35 <inspiran>	yup
déc. 14 21:12:03 <florian__>	"my 2 e-cents"
déc. 14 21:12:34 <florian__>	don't know why i thought to this
déc. 14 21:12:57 <inspiran>	one word is nicer, easier to google :)
déc. 14 21:13:06 <inspiran>	anyhow, it's not yet needed now
déc. 14 21:13:07 <florian__>	sure
déc. 14 21:13:32 <inspiran>	but i wouldn't want to have the name commerce in it
déc. 14 21:13:43 <florian__>	agree
déc. 14 21:14:14 <florian__>	a "magento" like or "ubuntu" like
déc. 14 21:14:30 <inspiran>	if you need do create some kind of a service based subscription site for organisations like unicef, you don't to have it labeled in the footer 'powered by sf-commmerce'
déc. 14 21:14:33 <florian__>	words that don't need to embed their usage
déc. 14 21:15:07 <inspiran>	maguntu :)
déc. 14 21:15:14 <florian__>	haha :)
déc. 14 21:16:23 <florian__>	but you're right, the question has not to be asked yet
déc. 14 21:17:01 <florian__>	let's see how things move until next week
déc. 14 21:17:08 <florian__>	let's write some scenarios
déc. 14 21:17:21 <florian__>	think of possibles solutions
déc. 14 21:17:24 <iampersistent>	yes, and I think we should post on the sfShop group and on the wiki that we are doing weekly meetings
déc. 14 21:17:39 <florian__>	yes i'm planning to do that
déc. 14 21:19:07 <iampersistent>	ok, cool
déc. 14 21:20:12 <inspiran>	so we would weekly meetings? ok :)
déc. 14 21:21:03 <iampersistent>	I think we should, just to keep on track
déc. 14 21:22:51 <inspiran>	but i must say honestly, it was a bit too early today
déc. 14 21:22:57 <inspiran>	i would prefer it a bit later
déc. 14 21:23:08 <inspiran>	like 19h GMT
déc. 14 21:23:27 <florian__>	ok for me
déc. 14 21:23:50 <iampersistent>	I'm ok with that
déc. 14 21:24:02 <inspiran>	ok
déc. 14 21:24:04 <iampersistent>	florian__ where do you want me to put the log?
déc. 14 21:24:06 <florian__>	cool :)
déc. 14 21:24:22 <florian__>	please send the on florian.klein [at] free.fr
déc. 14 21:24:46 <florian__>	i'm just missing first part, the rest is logged, but you can send them
déc. 14 21:25:04 <florian__>	thanks!
déc. 14 21:25:07 <inspiran>	heh, funny email address
déc. 14 21:25:10 <inspiran>	it's f^4
déc. 14 21:25:16 <inspiran>	hmm, never mind
déc. 14 21:25:22 <inspiran>	i thought i read four 'f'
déc. 14 21:25:29 <florian__>	hey, didn't noticed ;)
déc. 14 21:25:56 <florian__>	3 is not bad
déc. 14 21:25:59 <inspiran>	stupid question, how do i edit a wiki page?
déc. 14 21:27:41 <florian__>	do this work ? https://github.com/docteurklein/Symfony2-e-commerce/wiki/Home/_edit
déc. 14 21:28:10 <florian__>	i pushed you to the list of collaborators
déc. 14 21:28:37 <inspiran>	yep, works
déc. 14 21:28:57 <florian__>	if tou want, you can fork the wiki on a dedicated git repo
déc. 14 21:30:24 <florian__>	as seen here https://github.com/docteurklein/Symfony2-e-commerce/wiki/_access
déc. 14 21:31:41 <inspiran>	ah, not needed
déc. 14 21:31:46 <inspiran>	i got my page created
déc. 14 21:31:47 <inspiran>	https://github.com/docteurklein/Symfony2-e-commerce/wiki/Use-cases-Inspiran
déc. 14 21:32:53 <florian__>	good
déc. 14 21:32:55 <inspiran>	would you guys be interested in some kind of a webcast on which i explain a bit more how sap handles business process configuration?
déc. 14 21:33:58 <florian__>	sounds cool
déc. 14 21:34:10 <iampersistent>	florian__ I just sent the log
déc. 14 21:34:15 <iampersistent>	inspiran yes please :)
déc. 14 21:34:19 <florian__>	thanks
déc. 14 21:34:22 <iampersistent>	np
déc. 14 21:34:49 <inspiran>	what is interesting software to use?
déc. 14 21:34:55 <inspiran>	i'm not familiar what is handy
déc. 14 21:35:03 <iampersistent>	not sure on that
déc. 14 21:35:12 <iampersistent>	guys I have to go for now, I'll be around later
déc. 14 21:35:19 <iampersistent>	good talk, I feel it was very productive
déc. 14 21:35:58 <florian__>	yes thanks for all
déc. 14 21:36:04 <inspiran>	thx for being here all
déc. 14 21:36:05 <florian__>	very inspirative
déc. 14 21:36:13 <florian__>	I think your name is well chose :)
déc. 14 21:36:16 <florian__>	n
déc. 14 21:36:22 <inspiran>	heh :)
déc. 14 21:36:49 <florian__>	see you next week -- or before
déc. 14 21:37:40 <inspiran>	we can always remain in this channel
déc. 14 21:37:54 <florian__>	clearly a productive talk
déc. 14 21:38:01 <florian__>	yeah
déc. 14 21:38:48 <inspiran>	absolutely
**** FIN DU JOURNAL À Tue Dec 14 21:42:54 2010

**** DÉBUT DU JOURNAL À Tue Dec 14 21:42:54 2010

déc. 14 21:51:58 <inspiran>	florian_> do you like red wine?
déc. 14 21:52:07 <florian__>	i do :)
déc. 14 21:52:57 <inspiran>	maybe we should pick up a nice sounding red wine brand derivative name
déc. 14 21:53:05 <inspiran>	i know iampersistent likes wine too
déc. 14 21:53:06 <inspiran>	alecs?
déc. 14 21:54:10 <florian__>	not a bad idea!
déc. 14 21:55:47 <florian__>	I know a very good wine names "gewurtzraminner", but luckily, it's white wine ;)
déc. 14 21:58:07 <inspiran>	the name is not sexy, it sounds like a german gestapo officer
déc. 14 21:58:09 <inspiran>	:)