SambaPOS Development Guideline.

[emre]

This is a frequently asked question. First of all let me give some general instructions about open source development workflow.

There are two basic components of open source development. Issue List and Version Control System (VCS). Issue List is useful for planning and developer communication. SambaPOS users or developers can create issues. VCS is useful for tracking source code history and merging developers code.

Generally development flows as:

• Somebody (User / developer) creates an issue. Ideally issues are work pieces which takes at most 2 development days to complete.
• Project coordinator accepts issue.
• Developer reads accepted issues and chooses one.
• Developer creates a personal repository by forking / cloning main repository. This clone is a snapshot of main repository for developer use. While creating that clone developer gives information about the purpose of that clone.
• Developer downloads code (syncs clone with a local folder). Does his work locally and commits his work back to clone repository.
• Developer creates a "pull request" for notifying coordinator about the update. Each clone should contain modifications for only one issue.
• Coordinator reviews code and if everything is fine he merges it with main repository. That means further SambaPOS releases will contain these modifications.
• Developer deletes clone.
• Developer chooses a new issue, creates a new clone for fetching latest code with his (and other developer's) modifications.
• Workflow jumps to step 5..

What is the current status of SambaPOS?

Personally I actively develop V3 (https://github.com/emreeren/SambaPOS-3) and only make bugfixes for V2 (http://code.google.com/p/sambapos/). I transferred most V2 issues to V3 project and I'll implement these on V3. I frequently make big changes on V3. For this reason contributing to V3 version might be hard until it reaches beta state.

If you want to implement something create an issue and give some information. We'll continue our communication from there.

What will happen if you want to develop something different based on SambaPOS code?

SambaPOS community edition licensed with GPL. That means you can modify SambaPOS code and use it for your personal needs. If you'll redistribute it you have to publish all modifications as open source with GPL license without changing any copyright notices.

We also have royalty free commercial licensing option for SambaPOS V2. Unlike GPL this license permits redistributing / selling your application as a closed source product. That license also permits rebranding application with your brand but we only permit a single brand. Visit http://sambapos.org/en/content/sambapos-licensing for more information.

[khamlichi]

I would just suggest that the configuration sections of the software be in English and only in english, which means leaving these sections out of the internationalization process at all.
This has multiple advantages :
 - It will allow for easy documentation, for a start you only have to write one documentation (also help topics can be extracted from the source code if your document while coding), second poeple can translate it to thier language using google translate (this is because english translates very well to other languages but the opposite is not true) also poeple will be able to follow your video tutorials even when they don't speak your language.
 - almost all poeple in programming world know english or are accustomed to working with english software, so I suppose they would be very happy to find that sambaPOS speaks thier native language when talking to end user but speaks English when talking to them.
I hope my suggestion is useful.
Thanks for this great software, keep this fine work and I am sure every one shop in the world would use sambaPOS.

[khamlichi]

Hi,
I just faced a problem while trying to program an interface for sambaPOS, basicaly I am trying to create an easier interface to introduce products and to create menus, nothing fancy just something I could use to create a product and add it to a menu at same time and maybe improve on that in the future. then I was faced with this problem : one of the fields is called 'Order', I don't know about dotnet developpement but for my case I am trying to connect from a Linux box and a field named 'Order' is a little bit difficult to work with because it's a  reserved word in SQL language.

I hope samba3 developpement would take this into account : avoid reserved words in field names.

Again, Thanks for everything.

[emre]

Thank you for this useful Feedback!

[khamlichi]

I ended up ignoring the field and imposing a default value of '10' at the db level.
With my Interface I can now introduce articles and they will instantly show at menu, no need to make that extra step which is by the way very difficult for non technical poeple to deal with.

I also added the Tag option directly into my interface so submenus can be created at the very step of adding a product.

I basically added all of those fields in one form, upon user completing the form I insert one record in its respective table (I think 3 separate tables)

unfortunately I only develop for the web so I cannot contribute this code.

[dinhero]

Hi every one,
This project is simply great and I litterally want to be part of this. I have 18 years experience in IT with 10 in development (C#, FreePascal, C++, Mql4 ect...).

Please inform me how I can be part of the project as a developer ?

Big thanks !

Dominique

[emre]

Hello dinhero, welcome to SambaPOS project...
Are you familiar with DVCS's such as mercurial or git?

[Tha99]

I just be able to setup 2 terminals, thanks to erme ! By the way, I suggest that If one terminal has, for example, Table 5 open, the other terminals should don't be able to open the same Table.

For example, it should has a popup says, "The ticket is opened at another terminal"

Thanks again erme

[emre]

Hello Tha99. Table locking might be a problem in some cases. Waiters frequently check tickets for different needs and they left them open. If we force users to wait until other user closes ticket that might cause other issues.

Additionally we don't consider adding orders to a ticket from different terminals at the same time as an error. That may happen on busy periods. We tried handling error cases instead. For example it wont permit submitting new added orders if another user settles ticket or move ticket to another table.