Geolocation overhaul - Testers needed

[nickz]

11 hours ago, lesley said:

I have clients (canada) that have to offer two languages unfortunately. The french in Canada are proud and require most things be both in english and french. 

yeap that's why I believe letting people choose is the best way. I see many people putting up 2 and more language solutions in shops who haven't have their first sale. In oder to be customerfriendly, which in my view of it, it's the opposite of friendly.

[x97wehner]

24 minutes ago, nickz said:

yeap that's why I believe letting people choose is the best way. I see many people putting up 2 and more language solutions in shops who haven't have their first sale. In oder to be customerfriendly, which in my view of it, it's the opposite of friendly.

Yeah, auto set it but leave the option there to switch it as you've mentioned.

[nickz]

35 minutes ago, x97wehner said:

Yeah, auto set it but leave the option there to switch it as you've mentioned.

unfortunately not, i.e. have a look onto mastercard.com the force you over the IP.

Edited January 6, 2023 by nickz

[Mark]

On 1/5/2023 at 7:21 PM, datakick said:

Again, there is NOTHING to fix here, from the thirty bees perspective.

Thirty bees / ps16 always performed geolocation using maxmind database. Because maxmind stopped supporting database version 1, we had to fix it. When we were doing that, we though that it's a good thing to make this 'detect country' functionality pluggable, instead of depending on single implementation. So we extracted it to separate maxmind geolocation module.

We support both this new module, and geolocation functionality in core core. If you use these two together, you will have the same functionality that always existed.

This new pluggable architecture allowed ME (not thirty bees) to create another module that gets the geolocation information from cloudflare. This module is mine. I made it myself, in my free time. It is new functionality. It is not part of thirty bees native modules. From thirty bees perspective, this is just ordinary module by third party developer.

You don't have any rights to go on this forum and demand changes to that module. It is absurd. It is like you creating a new issue in thirty bees project demanding changes to Panda theme. 

 

One person controlling this entire website should never have been permitted. There should always have been a few people deciding what goes on on this website in a transparent process and certainly a feedback system to allow site owners to feedback about features.

I never claimed to have rights nor have I demanded anything other than important concepts to be considered instead of thrown out without due care..  but you have no consideration for site owners .... just your own plans and power and you refuse to listen to anyone.

You don't own this site so far as I know, but you do control it and you shut out others saying commonsense things like "get geolocation accurate'

Stop acting like an overlord and listen to others.

[wakabayashi]

38 minutes ago, Mark said:

Stop acting like an overlord and listen to others.

Do you know that this project is dead tomorrow, if datakicks or smile "have enough"?

Your behaviour is very disrespectful and without any reason. Datakick does merge a huge amount of PR in a fast manner. You seem to have no idea, what it means to lead this project...

[Briljander]

6 hours ago, Mark said:

One person controlling this entire website should never have been permitted. There should always have been a few people deciding what goes on on this website in a transparent process and certainly a feedback system to allow site owners to feedback about features.

I never claimed to have rights nor have I demanded anything other than important concepts to be considered instead of thrown out without due care..  but you have no consideration for site owners .... just your own plans and power and you refuse to listen to anyone.

You don't own this site so far as I know, but you do control it and you shut out others saying commonsense things like "get geolocation accurate'

Stop acting like an overlord and listen to others.

I think they have all the rights to decide what they want to do by themself as its financed almost alone by Smile. 

As you are proposing transparency, would be interesting to know how much you are bringing to the table? 

I think they listen and also merge alot of pull requests if it's relevant. If you hire your own developer or add pull requests by your own I think they will consider them too but I haven't seen much effort from your side at all.

[Mark]

On 1/15/2023 at 9:18 AM, wakabayashi said:

Do you know that this project is dead tomorrow, if datakicks or smile "have enough"?

Your behaviour is very disrespectful and without any reason. Datakick does merge a huge amount of PR in a fast manner. You seem to have no idea, what it means to lead this project...

This is a serious ecommerce site and it should be setup properly with website owners represented in the decision making process to at least some degree and there should not not be such huge responsibility on Datakick alone. I agree he does an excellent job to a high level of skill and commitment, but he does whatever he likes since there's noone else involved.

Although I dont code I have been paying as a "Generous supporter" but going forward I won't be again until there's a proper process for getting bugs and enhancements fixed that gets decided on by multiple people representing different angles including site owners. Hasn't anyone heard of project management/ agile/ scrum? And understands the importance of balance instead of one guy doing everything?

Geolocation is an absolute no brainer in terms of getting country location exactly right since so much depends on country be accurate.

People need to stop taking things so damn personally and get key things sorted like Geolocation and get running things far more professionally. This is not an attack on Petr so much as it is a desire to get this thing the focus it deserves instead of it being a few geeks doing whatever they like and telling me to go stick it because I raise questions.. when all Ive ever wanted is for this site to be awesome.

The problem really is that this site is not managed properly, its far too big for it to be a one man band.

I realise Smile has bought this off Lesley because he's able to and is a nice guy and it keeps Petr going, but this needs a bigger view so it brings in money and it can pay people to help, attracts module builders... instead of it being just a "good guy" type scenario. You are quite right wakabayashi, at some point that arrangement will die. Its far too fragile already if I can say a paragraph that terminally upsets everything and everyone bails. Something needs to be done now if things are THAT fragile. The codebase wont die though, it will live on.

Edited January 16, 2023 by Mark

[datakick]

7 hours ago, Mark said:

...

There are two distinct things we do in thirty bees company. Firstly, we maintain open source project. This means:

• we are keeping the codebase afloat - we adjust code to run on newer versions of php, database, php extensions, new versions of dependency libraries. Without this, nobody in 2 years could run thirty bees project on any up-to-date server
• We fix bugs in core and more than 100 modules, as we assumed responsibility for this code
• We maintain github repositories for core and those 100 modules.
  • We do code review for new pull requests.
  • We scrub new issues, deciding if the report is bug or enhancement request, trying to reproduce the issue, etc
  • We investigate and implement security patches that are reported by third party security advisors
  • We play the gatekeeper card here, and decide what makes it to the codebase and what not. We hate to do that, because every line that makes it to the codebase becomes our responsibility, and we have to fix all bugs it might cause. So if the PR have tendency to cause a lot of grief, it will not make it to the codebase.
• We maintain set of api services that provides
  • core updater functionality
  • translations
  • module updates and distribution
• We maintain forum, trying to help as much as possible
• We maintain store, web, demo, and other websites.
• and more

If you look closely, you will notice I did not mention new code or features. We don't do that. At least not as part of thirty bees project maintenance. This maintenance is actually what you are paying for, if you are a backer.  

We do create and release new code under open source license, though. But that code is actually not part of open source project maintenance. Thirty bees company offers paid support and custom development services that anyone can purchase. Smile does exactly this. His private company purchases a lot of support time from thirty bees company, and invest it into the area he is interested in. It was warehousing feature are, packs, feature management, multistore, etc. Some of this new code development is done in core and released for everyone to benefit from. Some of it is implemented in new modules, that are either private, or ready to make available for everyone to buy. 

This custom development is a private initiative, not a public project by thirty bees. It is paid by third party company. Decision what features will be implemented or enhanced is entirely up to the company that purchased support time.

Note that I play the codebase gatekeeper card here as well. I do not allow new code that could break the things for others. Some requests could be implemented very easily in a few minutes, but because they need to be reusable for everyone, it can actually take a few hours or even days to implement that in generic way. Smile is paying for that extra time, even though he does not benefit from it directly.

Anyone can contact us, purchase some custom development time, and implement any feature they want. We will be happy to provide that service. Or they can hire third party developer to do that for them. We will do the code review, and merge any PR as long as it does not break things for others. 

Everyone can contribute to the open source project. And if they do not like the way we do the gatekeeping, they can fork it and maintain their own version. @Mark says that I'm playing the overlord and decide for everyone, and it's true. That what open source maintainers do. Somebody has to be the bad guy that rejects bad contributions. I'm comfortable being that asshole, I'm doing my worst for a good of thirty bees community, at least I believe I do so.

Why are we maintaining this open source project? We don't really have to, now do we? I mean, Smile could fork and create his own version of thirty bees, hire me or other developer directly to maintain it for him. He would save a ton of money on development time, as there would be no backwards compatibility issue to solve. We could change anything and tweak everything directly in core. No modules, no overrides. No bugfixes for modules we don't use. No maintanance of code we don't use.

We are maintaining the thirty bees project because we like the community, and we like to give back. We will continue to do so as long as we feel that there is a community to work with, and that the community cares. Being a backer means a lot in this context. It helps offset the expenses directly related with code maintenance, and it shows that there are people invested. It's a nice and tangible metric. 

 

 

[the.rampage.rado]

@Mark I believe it's time for you to rapidly change your tone here. Nobody on this world owns you anything. If you don't like this project there are plenty of paid or premium options that you can migrate to.

If you like to help - do it with ideas not with negative criticism that helps nobody.

If there is more business there will be more developers. The community is small but healthy thanks to couple of members, @datakick included.

If I was you I would not cut the branch I'm sitting on.

@datakick and @Smile, guys keeps the great work! The project had never been so vibrant and alive. Plenty of GREAT additions in 2022 and this year is starting excellent. We're waiting for those new modules!

[Mark]

11 hours ago, datakick said:

There are two distinct things we do in thirty bees company. Firstly, we maintain open source project. This means:

• we are keeping the codebase afloat - we adjust code to run on newer versions of php, database, php extensions, new versions of dependency libraries. Without this, nobody in 2 years could run thirty bees project on any up-to-date server
• We fix bugs in core and more than 100 modules, as we assumed responsibility for this code
• We maintain github repositories for core and those 100 modules.
  • We do code review for new pull requests.
  • We scrub new issues, deciding if the report is bug or enhancement request, trying to reproduce the issue, etc
  • We investigate and implement security patches that are reported by third party security advisors
  • We play the gatekeeper card here, and decide what makes it to the codebase and what not. We hate to do that, because every line that makes it to the codebase becomes our responsibility, and we have to fix all bugs it might cause. So if the PR have tendency to cause a lot of grief, it will not make it to the codebase.
• We maintain set of api services that provides
  • core updater functionality
  • translations
  • module updates and distribution
• We maintain forum, trying to help as much as possible
• We maintain store, web, demo, and other websites.
• and more

If you look closely, you will notice I did not mention new code or features. We don't do that. At least not as part of thirty bees project maintenance. This maintenance is actually what you are paying for, if you are a backer.  

We do create and release new code under open source license, though. But that code is actually not part of open source project maintenance. Thirty bees company offers paid support and custom development services that anyone can purchase. Smile does exactly this. His private company purchases a lot of support time from thirty bees company, and invest it into the area he is interested in. It was warehousing feature are, packs, feature management, multistore, etc. Some of this new code development is done in core and released for everyone to benefit from. Some of it is implemented in new modules, that are either private, or ready to make available for everyone to buy. 

This custom development is a private initiative, not a public project by thirty bees. It is paid by third party company. Decision what features will be implemented or enhanced is entirely up to the company that purchased support time.

Note that I play the codebase gatekeeper card here as well. I do not allow new code that could break the things for others. Some requests could be implemented very easily in a few minutes, but because they need to be reusable for everyone, it can actually take a few hours or even days to implement that in generic way. Smile is paying for that extra time, even though he does not benefit from it directly.

Anyone can contact us, purchase some custom development time, and implement any feature they want. We will be happy to provide that service. Or they can hire third party developer to do that for them. We will do the code review, and merge any PR as long as it does not break things for others. 

Everyone can contribute to the open source project. And if they do not like the way we do the gatekeeping, they can fork it and maintain their own version. @Mark says that I'm playing the overlord and decide for everyone, and it's true. That what open source maintainers do. Somebody has to be the bad guy that rejects bad contributions. I'm comfortable being that asshole, I'm doing my worst for a good of thirty bees community, at least I believe I do so.

Why are we maintaining this open source project? We don't really have to, now do we? I mean, Smile could fork and create his own version of thirty bees, hire me or other developer directly to maintain it for him. He would save a ton of money on development time, as there would be no backwards compatibility issue to solve. We could change anything and tweak everything directly in core. No modules, no overrides. No bugfixes for modules we don't use. No maintanance of code we don't use.

We are maintaining the thirty bees project because we like the community, and we like to give back. We will continue to do so as long as we feel that there is a community to work with, and that the community cares. Being a backer means a lot in this context. It helps offset the expenses directly related with code maintenance, and it shows that there are people invested. It's a nice and tangible metric. 

 

 

[Mark]

18 minutes ago, Mark said:

12 hours ago, datakick said:

There are two distinct things we do in thirty bees company. Firstly, we maintain open source project. This means:

• we are keeping the codebase afloat - we adjust code to run on newer versions of php, database, php extensions, new versions of dependency libraries. Without this, nobody in 2 years could run thirty bees project on any up-to-date server
• We fix bugs in core and more than 100 modules, as we assumed responsibility for this code
• We maintain github repositories for core and those 100 modules.
  • We do code review for new pull requests.
  • We scrub new issues, deciding if the report is bug or enhancement request, trying to reproduce the issue, etc
  • We investigate and implement security patches that are reported by third party security advisors
  • We play the gatekeeper card here, and decide what makes it to the codebase and what not. We hate to do that, because every line that makes it to the codebase becomes our responsibility, and we have to fix all bugs it might cause. So if the PR have tendency to cause a lot of grief, it will not make it to the codebase.
• We maintain set of api services that provides
  • core updater functionality
  • translations
  • module updates and distribution
• We maintain forum, trying to help as much as possible
• We maintain store, web, demo, and other websites.
• and more

If you look closely, you will notice I did not mention new code or features. We don't do that. At least not as part of thirty bees project maintenance. This maintenance is actually what you are paying for, if you are a backer.  

We do create and release new code under open source license, though. But that code is actually not part of open source project maintenance. Thirty bees company offers paid support and custom development services that anyone can purchase. Smile does exactly this. His private company purchases a lot of support time from thirty bees company, and invest it into the area he is interested in. It was warehousing feature are, packs, feature management, multistore, etc. Some of this new code development is done in core and released for everyone to benefit from. Some of it is implemented in new modules, that are either private, or ready to make available for everyone to buy. 

This custom development is a private initiative, not a public project by thirty bees. It is paid by third party company. Decision what features will be implemented or enhanced is entirely up to the company that purchased support time.

Note that I play the codebase gatekeeper card here as well. I do not allow new code that could break the things for others. Some requests could be implemented very easily in a few minutes, but because they need to be reusable for everyone, it can actually take a few hours or even days to implement that in generic way. Smile is paying for that extra time, even though he does not benefit from it directly.

Anyone can contact us, purchase some custom development time, and implement any feature they want. We will be happy to provide that service. Or they can hire third party developer to do that for them. We will do the code review, and merge any PR as long as it does not break things for others. 

Everyone can contribute to the open source project. And if they do not like the way we do the gatekeeping, they can fork it and maintain their own version. @Mark says that I'm playing the overlord and decide for everyone, and it's true. That what open source maintainers do. Somebody has to be the bad guy that rejects bad contributions. I'm comfortable being that asshole, I'm doing my worst for a good of thirty bees community, at least I believe I do so.

Why are we maintaining this open source project? We don't really have to, now do we? I mean, Smile could fork and create his own version of thirty bees, hire me or other developer directly to maintain it for him. He would save a ton of money on development time, as there would be no backwards compatibility issue to solve. We could change anything and tweak everything directly in core. No modules, no overrides. No bugfixes for modules we don't use. No maintanance of code we don't use.

We are maintaining the thirty bees project because we like the community, and we like to give back. We will continue to do so as long as we feel that there is a community to work with, and that the community cares. Being a backer means a lot in this context. It helps offset the expenses directly related with code maintenance, and it shows that there are people invested. It's a nice and tangible metric. 

 

 

All of this is true and well stated, thanks and we all certainly do appreciate the work that goes on on just keeping the animal alive.

If you read between the lines, we are saying similar things in many respects.

What I'm saying is that I think the project deserves much more resource than it gets, and that means others directly contributing more to it and getting paid to do so, or some other tangible benefit, by helping. This includes module developers as well as core.

I realise its a nice community and that I'm the only asshole here because I say challenging things, but I wouldnt bother with this if I didnt also care and want better things for the site.

There's far too much work here for just one man to both manage everything and be lead developer for.

There's vast teams out there working on much smaller codebases than this one.

The whole thing is far too under resourced for what it is.

 

Edited January 16, 2023 by Mark

[Briljander]

2 hours ago, Mark said:

All of this is true and well stated, thanks and we all certainly do appreciate the work that goes on on just keeping the animal alive.

If you read between the lines, we are saying similar things in many respects.

What I'm saying is that I think the project deserves much more resource than it gets, and that means others directly contributing more to it and getting paid to do so, or some other tangible benefit, by helping. This includes module developers as well as core.

I realise its a nice community and that I'm the only asshole here because I say challenging things, but I wouldnt bother with this if I didnt also care and want better things for the site.

There's far too much work here for just one man to both manage everything and be lead developer for.

There's vast teams out there working on much smaller codebases than this one.

The whole thing is far too under resourced for what it is.

 

You are right about this and the business side had always been the problem with Thirtybees. 

I also agree that it's a fragile project relying on few people.

But still, Smile and Datakick are the ones keeping this alive right now. 

I think it's ok to come up with criticism but you can still do with a better tone than you first did and it's also hard to demand that much for the small amounts paid the project.

 

[Mark]

My suggestion is to involve more people in the decision making about this website.

It isnt fair on Datakick that everything rests with him, and it isnt fair on the rest of us that he alone decides everything... even if he does his best. This isnt Datakicks' website or Smile's, its all of ours.

We all have businesses tied to this, it isnt just about Datakick and Smile and we should all have some right to have some say over some aspects and we certainly should not have NO rights as Datakick has said. WTF?!! Overlord alright! I dont care who "owns" the company, we should all have some involvement and input into some things.

All TB owners should be able to participate in some aspects of this so that its more democratically decided and less of a burden to Datakick to decide for all of us.

There's obviously software around that can do this job so its not a big deal, probably it can even be enabled in github. Owners can feedback about features and see and contribute to these, priorities and to some degree some bugs.

Personally I scarcely notice anything that gets done on the website, its all just countless little things not visible to the user's eye, nothing significant as far as features ever seems to change much and the bugs Ive always seen and kept quiet about still mostly exist. If I report about key things like GeoLocation it gets chucked out because it doesnt matter to Datakick!

More resource is needed!

Much stuff we have no idea about whats coming up, such as warehousing changes and info about the forthcoming warehouse module datakick and smile are working on.

We don't we get this info?? Why should it be cloak and dagger? I put a post out seeking details... noone replied... ASM Warehousing is major.... I certainly want to get an idea of what's planned there....

[Briljander]

For $10 a month and no working effort I don't think you can expect that much influence. 

Why don't you hire another fulltime developer that can work alongside with Datakick? You can develop whatever custom stuff you want to your site but still create PRs and try to stay compatible with this project that you care so much about? 

If i remember it right Smile asked in the forum for co-founders to the warehouse module. Did you sign up for that? 

 

[datakick]

6 hours ago, Mark said:

My suggestion is to involve more people in the decision making about this website.

It isnt fair on Datakick that everything rests with him, and it isnt fair on the rest of us that he alone decides everything... even if he does his best. This isnt Datakicks' website or Smile's, its all of ours.

We all have businesses tied to this, it isnt just about Datakick and Smile and we should all have some right to have some say over some aspects and we certainly should not have NO rights as Datakick has said. WTF?!! Overlord alright! I dont care who "owns" the company, we should all have some involvement and input into some things.

All TB owners should be able to participate in some aspects of this so that its more democratically decided and less of a burden to Datakick to decide for all of us.

We are not a product company. I would like that, but that's just not realistic. As you wrote -- there isn't enough resources for that. We would need product team (maybe even multiple product teams, for different feature areas). Each team would have to compose of:

• few developers to implement new things
• Product manager that would understand the given domain, plan new features, communicate with external stakeholders (merchants) and incorporate their feedback into the roadmap
• QA engineers, as new code have a great tendency to break compatibility and other stuff
• Tech and docs writer to communicate new features to target audience  

We would need at least one such team. But more would be better - one of them focusing on warehousing, other on front end features, etc.

And then, we would need marketing and sales team to promote the new stuff product team would be creating.  

All of that might bring new users for the system. That's not revenue, though. We would need some monetization strategy that would utilize this big user base -- maybe module selling. What else? Maybe support or custom development, but that does not scale well. 

To get there, we would need a serious investor that would give us hundreds of thousands of euros. And we would burn through them in no time.

That's not realistic.

Therefore, we went for the second best think. We created a support-based company. We provide limited maintenance and no new features  development. We don't actually need huge user base to fill ours support capacity. 

Since we are not developing a product, I don't see much reasons why to include you into any decision making. You guys would talk a lot, decide on a nice set of great new features you want us to implement, and then be upset that we do not do that. Because we don't have that resources.

We could include you into bug prioritisation, that's true. You could tell us what bugs give you the biggest headaches, and we can try to fix them first.  

6 hours ago, Mark said:

Personally I scarcely notice anything that gets done on the website, its all just countless little things not visible to the user's eye, nothing significant as far as features ever seems to change much and the bugs Ive always seen and kept quiet about still mostly exist.

Please read what I wrote in previous post. We are maintaining things. Maintenance indeed consists of countless little things that should not be visible to end user, ideally. We fix warnings before new version of PHP upgrades them to errors. It's like removing skin marks before they turn into cancer. 

We do fix a lot of bugs. Some of them might not affect you. Some of them affect you only a couple times a year. 

Is there a bug that is causing you trouble every day? I personally don't know about any. If you experience some, please let us know. 

6 hours ago, Mark said:

If I report about key things like GeoLocation it gets chucked out because it doesnt matter to Datakick!

Once again -- there is no bug in geolocation feature in the core. You have complained about configuration of a third party module. That' s the problem of that module, not core. 

It's like you were complaining to the car manufacturer that the radio you purchased somewhere and installed into the car does not have a volume button. I agree that volume button is important, but it is not a bug in the car. 

6 hours ago, Mark said:

Much stuff we have no idea about whats coming up, such as warehousing changes and info about the forthcoming warehouse module datakick and smile are working on.

We don't we get this info?? Why should it be cloak and dagger? I put a post out seeking details... noone replied... ASM Warehousing is major.... I certainly want to get an idea of what's planned there....

The new warehousing module is build for Smile specifically. It replaces his current external ERP integration, so the scope and functionality requirements are very clear. There is nothing to discuss with community, because the first version is not intended for you, really. We don't need to burned ourselves with additional feature requests at this moment. There is a huge task backlog already.

Once this initial version is completed, it will be released as a paid module. That will be the time for community to test it, and we will take notes and requests for further enhancements.