As written in #84

Scoped Maintainers have the same mission as Project Maintainers, but over a limited scope (e.g. a project, a repository, or a technology).

Currently, the GitHub organisation of the open source project contains also some repositories for non open source code, used for the PrestaShop company.

It's time to split that and put what is not related to the open source project into an other organisation, let say "prestashop-company". And then clean up and archive other stuff if needed.

Todo:

• Create a GitHub organisation for the company code
• Move the repositories
• Clean the open source project organisation from non open source code

Prerequisites

• I understand and accept the project's code of conduct
• I have already searched in existing features request and found no previous suggestion of this feature.

Is your feature request related to a problem?

This invitation, and the OpenSSF in general, aims at improving software and supply chain security across the open source software world.

Describe the solution you'd like

Hi

My name is Georg Kunz and I work with the Developer Best Practices Working Group of the Linux Foundation's Open Source Security Foundation (OpenSSF) "Great Multi-Factor Authentication (MFA) Distribution Project".

We'd like to give your project free MFA hardware tokens from Google and GitHub, for use by your maintainers. We'd especially like to give them to any of your maintainers who aren't already using any. Our goal is to help improve the security of open source software (OSS)/Free Software projects. For example, these tokens can counter attacks that release source code updates and/or packages using stolen passwords.

By 2021-12-20 and preferably much sooner, please let me know:

1. If you want any tokens, and if so...
2. How many Titan tokens from Google (up to 5)
3. How many Yubikey tokens from GitHub (up to 5)
4. The private email address to send codes to (this email must not go to the public, as these are use-once codes that can be used to get the tokens)
5. If you could use more, how many more.

We would send you coupon codes and validation codes to the private email address. You would then distribute those codes to the maintainers you choose. The recipients would use the coupon codes and validation codes to "buy" the tokens from the Google Store and/or GitHub Shop, who would ship the tokens directly to recipients. These codes are use-once, so make sure you can keep the codes private until they're used by the intended person.

Important: The Google coupon codes must be used by 2021-12-31 on the Google Store or they expire.

How can you trust us? You don't need to. You would get the MFA tokens from Google and GitHub; we're simply offering codes to make them no-cost. We'll provide some documentation on how to use them, but you don't need to use our documents.

To qualify, each token recipient must:

1. Be a maintainer or contributor to this critical open source software (OSS) project, or to another OSS project that this project depends on (the dependency may be indirect).
2. Try to use an MFA token once they receive the token. We'd like recipients to use MFA tokens from then on, but at least try.
3. Not reuse the token between different people (the token must not be shared).
4. Consider providing feedback to us (so we can try to fix problems).

We also need each project that receives coupon codes and/or validation codes
to tell us these numbers (preferably within 30 days of getting the codes):

1. How many tokens did you distribute from just Google? From just GitHub?
2. How many people received tokens from just Google? From just GitHub? From both?
3. How many people didn’t have hardware tokens they used for OSS who received tokens from just Google? From just GitHub? From both?

We ask for this information so we can tell others some simple measures of success. We don't need nor want the names of any individuals participating. It's fine to ask the people who got the codes for that information and provide a best-effort summary.

The MFA tokens are shipped from the US. They can be shipped internationally, but there are various limitations on where each can be shipped.

In particular, we can't ship somewhere if that is forbidden (sanctioned) under US law. So at this time we are unable to ship to individuals in China, Afghanistan, Russia, Ukraine, North Korea, Iran, Sudan, and Syria. Sorry about that. See the Google and GitHub sites for more shipping information. More sanction information is available.

For more information including how-tos and other setup information can be found at the "Great Multi-Factor Authentication (MFA) Distribution Project" site.

Best regards
Georg

Alternatives you've considered

No response

Additional context

No response

Currently, only core devs, employees of the PrestaShop company can build and make a release. At one point, people from the community should be able to do it too.

Also, continuous improvement in the devdocs about how to build in the project would be great.

Add a page listing all the project's modules (native or otherwise), with:

• Category
• Title
• Image
• Description
• Link to Github release page, where you should be able to download the module package (not just sources)
• Link to user docs article

Mockups

Figma - V1
Figma - V2

I am Julius. Web developer from Lithuania.

I would like to become a maintainer of PrestaShop Core 😛

Background

I am working with Prestashop migration to Symfony for almost 2 years now.
During those years I've developed quite some knowledge of PrestaShop technical specifics as well as good communication with PrestaShop team.
Even when I am not working on Prestashop migration, I develop modules/custom solutions to help merchants succeed. So I always stay close to PrestaShop and improve my technical & E-commerce domain knowledge.

Why

I hope becoming a maintainer would allow to speed up migration process, especially during product page migration & other pages where it requires working in little focused teams. It would allow to merge PR's faster and remove some workload from other members.

Currently, the demo-retro is only for the PrestaShop company employees. And even if the demos are recorded, they are only available internally.

In order to show how the work of the PM and dev teams is advancing, it would be great to publish the videos of the demo on a public platform.

Todo:

• record demos
• create a dedicated channel to host the videos (wip)
• upload the videos and communicate about it

There are already two interesting resources:

• the file organisation on the Devdocs
• The Current Architecture on the Build Blog

However, we can see when a new core developer joins the team at PrestaShop that this is not easy to start without mentoring from the colleagues. This must be even more difficult for people outside the company.

That's why the architectures description must be improved and describes extension capabilities (e.g: web services and modules, ...), and more.

Once a build is released, the installer of the software is available on GitHub and on the Download.

At the moment, the md5sum of the zip is not visible on the download channels, and only available to the auto upgrade plugin.

This information should be public, to allow anyone who download the software to check that they have an original/genuine archive (non modified)

Members of the PrestaShop project come and go, and when they leave the project because they do not wish to invest time in it only their name remains in the Changelog.

I'm thinking: maybe we could gift something to long members of the project who quit it for some new adventure. And the idea I have is a life-long role: alumni.

Alumni could be for any role of the project. For the maintainer role, here's what I have in mind:

• when a maintainer wishes to stop his role, if he did it for more than a year, he is offered the role of alumni
• maintainer alumni would keep partial merge rights (likely to committers, another role I suggested in PR #79)
• maintainer alumni could would be invited to discussions and events
• maintainer alumni could have some voting rights (to be defined)
• maintainer alumni could keep this role for life, and would only lose the role if doing some major offense like willful negligence, intent to harm the PrestaShop project or violating the Code of Conduct

For example I would like to offer the alumni role to @Quetzacoalt91 for his outstanding contribution to the project for many years

Discussion platform are not that great currently to foster and grow a community. A few actions have been identified.

Moving every technical discussion to GitHub will allow to have all in the same place, and within the same application. This will greatly simplify the life of developers who are opening pull requests, and linking them to issues.

The forum was abandoned: no moderation, a lot of technical issues, security upgrades to be done, spam and trolls, and many more issues to fix to attract people again, and gain trust from its users.

All active open source project have a Chat. It used to be on IRC, mostly on freenode.org, but today the ecosystem use a lot "Slack". It is time for the PrestaShop community to have a Slack, to be used by developers, contributors, users, and all its personas to exchange.

1. move technical discussion to GitHub
2. make the forum great again
3. create a chat for the community

Good morning,

My name is I-have-no-name and I'm from China.

Regarding the link repository that is being created here: https://github.com/PrestaShop/open-source/tree/master/modules-themes with reference to modules and free templates from third parties.

I think that a specific quality control should be created regarding free modules and themes from third parties, not just any module should be linked, there should be a quality control of the code (we are not talking only about the license), but when someone in the future uses this module/template they should not have unpleasant surprises.

Obviously I am speaking from a phantom user, but I know first hand the problem of not having a high quality control.

Greetings and blessings,

A Code of Conduct is now an expected document for any good open source project. And the most important projects already have one.

This document describes an expected behavior based on good will, openness and respect, for discussions on all the communication channels of the PrestaShop project, between all the people:

• Online, e.g on the forums, GitHub, or social networks
• In real life, e.g during events and meetups
• With the many languages, cultures and origins of the community

A Code of Conduct must be enforceable.

Todo:

• write a french version with a lawyer
• make an english translation
• review of both version by a lawyer
• submit to the community for feedback
• apply it on communication channels

As written in #79

This Pull Request is a proposal to add the role of Committer in the project.
A Committer is a contributor who, after demonstrating his skills and motivation towards helping the review of contributions, would be granted a partial approval power on pull requests for the Core repository. As you can see in the PR content, a committer would be able to approve Pull Requests however a Pull Request would be accepted only if at least one maintainer approved it.

Please participate on the Pull Request

The Arial font is proprietary, and not necessarily available on open source platforms. I suggest using Liberation Sans, an open source font that's metric compatible with Arial.

As written in #83

This item aims to clarify multiple implicit things we do when reviewing Pull Requests

A good way to track a topic is to group old issues of the same topic in a new one (call that Epic, or Story or whatever). This will help to track and set priorities in project management.

This will also show that old issues are not forgotten and reinforce the interest for user to spend time to report them.

Finally, it makes it more easy for users to find those issues if they are concerned, to document them, and for a contributor, to provide an eventual "global" fix.

Many possibilities here:

• Create a dedicated event
• Open a technical track on one of our current event (Varsovie as already content in english)
• Create a track on an other event, like Paris Open Source Summit

What is important here is to have a call for paper and a selection committee, in order to give the voice to community (of course employees of the PrestaShop company should propose talks too). The idea is to follow the way other big open source communities are doing: the community is speaking to the community.

There is currently this page in the devdocs about the tests suite:
https://devdocs.prestashop.com/1.7/testing/how-to-launch-tests/
It provides also a link the readme, and it allowd anyone to run the tests.

However, we don't provide tutorials to explain how to write different kind of tests for the project. That's currently missing. Many people have raised their interest to have resource, in order to:

• add tests to the modifications they do for their customers
• contribute tests or write tests to validate their pull requests

Todo:

• Write tutorials about unit tests (PHPunit + Behat)
• Write tutorials about sanity tests (Pupeteer)
• Write tutorials about functional tests (Pupeteer)
• Write tutorials about end to end tests (Pupeteer)

See also #8

There are other ways to contribute than code:

Let's write about that in the devdoc and improve this page with links:
https://devdocs.prestashop.com/1.7/contribute/

Todo:

• list the different ways to contribute
• add content to the devdoc

In order to make it easy for non developers to study the dependencies of the PrestaShop open source software, the Devdocs must include a tree of the dependencies, for the core and the native modules.

This must include:

• Integrated dependencies in the repositories
• Composer managed dependencies
• NPM managed dependencies
• The dependencies of the dependencies
• And in general, all third party code and libraries used in the project.

A difference must be made between:

• The dependencies that are built and redistributed in the PrestaShop installer of a release (the zip file)
• The dependencies used only for development purpose and that are not included in the build

There are two aims:

• Study and identify dependencies that are not compatible with the OSL license for redistribution
• Generate comprehensive "third party licenses" files with lists and licences of all the dependencies in the project builds (core and native modules)

In general, please note that the PrestaShop open source project is distributed under the OSL license. It means that in the build/release, only third party code and libraries distributed under the compatible licenses must be used:

• MIT
• BSD
• EUPL
• AFL
• OSL

"Development only" dependencies are not built and distributed in the software, so this license restriction does not apply.

Hello everyone,

after discussion with Valentin, I would like to become a scoped theme maintainer.

What I would like to do

• I would like to be a Hummingbird and Classic repository maintainer.
• (if possible) I want to be able to approve SEO, UX and performance related PRs in the core respository, thus improve the quality of the frontend. Don't know if this is even possible, maybe not, but you can try it and kick me out if I sniff my nose where I should not. 👍

Why I want to have this right

• We are doing work together with @NeOMakinG and it would greatly improve the workflow if I didn't have to ask him for everything. :-)
• I see a lot of facepalm PRs from people with brutal backend skills, but little front end skills. Nobody can know everything, but people must combine their powers in order to produce high quality code.

Why you could accept me

• Doing ecommerce since 2008, working with Prestashop since 2015.
• I am taking care of our family business with kitchen appliances + few other stores from multiple fields. Examples - kid toys store, food delivery, wood, electric engines, media agency, bike store, papeteria and others. So I have inputs from both B2C and B2B stores, or combined.
• I know the real needs of both small and medium sized companies, I know the real struggles of employees, I know the real struggles of shop owners.
• I contribute to important topics - https://github.com/PrestaShop/PrestaShop/pulls/Hlavtox. 300+ contributions.
• I translate Prestashop - got Czech to 100% translated & validated.
• I think I am quite good at SEO - https://user-images.githubusercontent.com/6097524/138665747-a26ed1b9-709a-4ccb-b90b-bbefe349181a.png
• My theme lighthouse:
  

Following @boubkerbribri application as maintainer, there is a page about Software Developers in Test in the maintainer guide

https://www.prestashop-project.org/maintainers-guide/project-organization/

It defines:

Software Developers in Test provide technical vision, review contribution and write automated tests, which help accelerate the testing process.

This is not defined enough.

In order to complete Boubker's definition of his role in the project we need

• To define the rights and duties of Software Developers in Test about the `tests/UI' (see link) folder on the Core repository
• To define the maintainer rights on https://github.com/PrestaShopCorp/modules-testing-library if it was transferred to PrestaShop organization

Many contributors are frustrated to see that their pull request are not merged, or that it takes times to merge.

Many things can be done here:

• Document priority and severity
• Document the code review process
• Document the pull request prerequisites and show example (WIP: documentation on how to write tests and other related topics are currently being written)
• Publish specifications and mockups (WIP -> PrestaShop/prestashop-specs)
• Improve the sorting process of issues with projects (improvements are currently being proposed and tested)

after uploading the modules to the prestashop, an invalid security token error popped up, it is no longer possible to click on uploading the module does not respond. Don't know what it can be? I tried PHP changes to clear cache, other browsers. but it doesn't work, please advise.

In order to improve the maturity of its intellectual property, the PrestaShop project needs to know well the authors of its code.

The best way is to ask code authors to sign a CLA, or to accept the terms of a DCO. (It means also signing commits, and other stuff like that)

Let's study what is the most appropriate, and list what are advantages and flaws of both. And then take a decision with the community.

https://www.prestashop-project.org/ uses standard favicon, maybe a prestashop favicon would be pretty?

Ok, I was scared to be the first one 🙈 let's be a second one 💪

I'm Krystian, I'm 29 y/o web dev from Poland

working with PrestaShop since I was 18, in industry since 2006 (yes, I started doing commercial projects in school)

How can I help?

I want, and I think I can, help with both, transition to Symfony (in v8), and to keep PrestaShop features as stable as possible with future work related to multi-store (in v1.7), I want to help with finishing this first transition period (back office refacto) - by discussing, reviewing and last but not least, coding.

Why?

I'm with PrestaShop for a long, long time, some of you may recognize me from the forum, from Github, Gitter and maybe recently from Slack. My journey with PS started somewhere around v0.8b, SVN, fancy rounded design and all of that ;)

From around 2008 PrestaShop has been main tool for me, my team and my company, thanks to this I feel confident that I can provide additional value, not only related to coding, but decision making, analyzing community and merchant needs etc.

I'm an author of some popular modules in PrestaShop eco-system (both world-wide, and here in Poland), I sold my themes and modules to over 10.000 stores based on PS, thanks to this I know what module developer needs are, what we need to keep and improve when it comes to themes, I know where we should keep PrestaShop as backward compatible as possible.

What else?

I'm programmer with a lot of experience, but because of PrestaShop and working daily with legacy code, doing hybrid solutions for PrestaShop from 1.5 to 1.7, I don't feel confident enough (yet!) with DDD, tests were not always been there, and there's still learning curve for me in some aspects, but I treat this "issue" as a motivation to move forward, along with PS 😎

Last but not least, I wasn't the most active member in past months, but there were some reasons for that, aside from just operating on a fairly large scale commercially with PrestaShop and less time, I was the one who was skeptical about version 1.7 and the fact that the migration to Symfony would not happen within the one long gap between releases. I was scared about many things, lack of final architecture design and concepts (because of this Product and Module pages have to be reworked now), backward compatibility (some multi-store issues are still there) etc.

The fact that the core team of PrestaShop has changed quite a lot in recent years was also not encouraging, I had great contact with many people who are no longer in the company, but there are also many with whom I see a lot of knowledge, motivation for PrestaShop to be a better software and the kind of people you just want to work with. This is why I'm creating this issue.

Oh, and it's no secret that I am an introvert, I'm not at many events, so there is nothing to brag about in this aspect 🤷🏻‍♂️

Fun fact: I'm an author of first (and wrong 🙈) PrestaShop PR on GitHub PrestaShop/PrestaShop#1

Salutations à tous ✌🏻

About me

I’m Boubker, 29 years old and I’m a QA automation Lead at the PrestaShop company.

The beginning

Back in 2019, when I first discovered the project, I didn’t know much about Open-source (yeah, I did the mistake open-source = free of charge).
Then I joined the team and discovered an entirely different context and concept, full of love, commitment and collaboration.

Why?

As a member of the QA team, and with the help of the team, I’m responsible for:

• Create new UI tests and maintain old ones.
• Ensure the quality of tests to be 100% reliable.
• Analyse tests outcome for nightly builds.
• Analyse tests outcome on CIs (on different projects).
• Update tests dependencies.
• Run all campaigns on some pull requests.

So why become a maintainer?

I could think of 3 reasons to become a project maintainer :

1. It’s the consequence of what I’m doing right now, to ‘Ensure the quality of tests’, I have to review more PRs linked to tests.

2. As a contributor, I’m committed to the Project’s improvement. As a maintainer, My commitment will not be just for the project, but also for contributors. It will help me discuss with them the improvements, how to add tests, adding documentation …

3. Becoming a Maintainer will also open up the possibility to add and maintain more tools for contributors, for example, The new modules testing library that should be open source soon.

Some numbers

You can find the details about my contributions here.

When opened in OpenOffice4, arrow graphics on slide 3 do not render correctly.

Steps to reproduce:

Open .pptx file in OpenOffice and look at slide 3.

Is your feature request related to a problem?

⚠️ Before working on this issue, we are waiting to know if the product sheets of the native modules will be removed from addons or not

It's not possible to download modules of the OS project on addons

Describe the solution you'd like

As a user I should be able to download the modules of the OS project on prestashop-project.org

Create a new page called "" with:

• A link to the user doc, explaining how to download and install a module.

• In each category, modules should be sorted from A to Z (only the display name is displayed, not the technical one)

Administration
autoupgrade
ps_dataprivacy
psgdpr
ps_faviconnotificationbo
ps_emailalerts
statsbestmanufacturers
statsbestcategories
statsbestcustomers
statsbestproducts
statsbestsuppliers
statsbestvouchers
statscatalog
statscheckup
statsdata
statsforecast
statsnewsletter
statspersonalinfos
statsproduct
statsregistrations
statssales
statssearch
statsstock
dashactivity
dashgoals
dashproducts
dashtrends
graphnvd3
gridhtml
pagesnotfound
ps_bestsellers
ps_googleanalytics

Design & Navigation
blockreassurance
blockwishlist
contactform
productcomments
ps_banner
ps_categorytree
ps_contactinfo
ps_currencyselector
ps_customeraccountlinks
ps_customersignin
ps_customtext
ps_facetedsearch
ps_featuredproducts
ps_imageslider
ps_languageselector
ps_linklist
ps_mainmenu
ps_searchbar
ps_shoppingcart
ps_themecusto
ps_brandlist
ps_newproducts
ps_specials
ps_supplierlist
ps_viewedproduct

Facebook & Social networks
ps_sharebuttons
ps_socialfollow

Payment
ps_checkpayment
ps_wirepayment
ps_cashondelivery

Promotion & Marketing
ps_crossselling
ps_categoryproducts
ps_emailsubscription

Traffic & Marketplace
gsitemap

For each module, we should display:

• Image of the module
• Display name of the module
• Short description of the module
• Link to the "release" page of the module on GitHub to allow to download the final zip of the module (ready to be installed without having to do the "composer install")

The user doc for merchants is quite good and up to date, thanks to the good work from the PM team of the PrestaShop company.

However, the project documentations, for developers of users, one important point is missing: how to run big PrestaShop websites with high traffic.

This must be addressed to gain trust and confidence for big users of the community, or for users looking for software with better reputation on performance.

Todo:

• find a good tech with skills, experience, and time
• investigate (started)
• write docs and tutorials
• publish doc
• if needed, fix identified issues in the software

On open-source/modules-themes/, you still have a link to the classic-rocket theme, that is outdated since 2018. The current repo of the classic-rocket theme is found here https://github.com/prestarocket-agence/classic-rocket/

The open source project should be installable without dependency of the PrestaShop company servers. If they are available to provide other features and content, this is a plus. But it must not have an impact on usability, nor on the performance of the software.

See also: PrestaShop/PrestaShop#10456

As written in #84 (comment)

Limited scope does not necessarily mean limited rights, so it can introduce ambiguity if it is not clear.

We need to clarify what rights and permissions are granted to scoped maintainers regarding to their scope

PrestaShop is a large project and many people, with different roles, duties, skills work on it!

There's a lot of things we do and follow everyday that we need to write down.

There's a lot of things which are not clear, confused and that need clarification.

And like any group of humans, the structure, the rules and the guidelines evolve over time.

This epic gathers the different topics (today and the ones we'll find later) about this work

Need to write down something that we already do/follow

• #88
• #94

Need to define or clarify something that already exist but is not clear

• #82
• #89
• #95

Extending the current structure and rules

• #86
• #87

GitHub is not a CMS.
We should take the content of this github and generate a static website from it using GitHub Pages and Jekyll.

I'm willing to do something minimalist as I would like to discover Jekyll, I can use this topic as a POC.

I found 3 Jekyll themes I think are suitable for this repository:

https://jekyllthemes.io/theme/doks-documentation-jekyll-theme
https://jamstackthemes.dev/theme/jekyll-yamt/
http://jekyllthemes.org/themes/SIMPLE-GREEN-TECH/

Please check them out, tell me which one seems all right and I can

• generate a static website using Jekyll and the chosen theme from this repository
• tune a little the chosen theme to give it a "prestashop" tone, following https://build.prestashop.com/ UX chart

When the new testing suite will be available, write about it asap in order to show the work done, the improvements, and what still needs to be done.

The testing suite is the key to improve the overall quality of the software and reduce regressions.

See also #20

Currently, there is no comprehensive list of modules and their repository on the devdoc. The only resource available is here:
https://github.com/PrestaShop/PrestaShop-modules

Let's complete this page of the devdoc with a new section, in order to add the modules that had no equivalent in 1.6:
https://devdocs.prestashop.com/1.7/modules/introduction/

This will be the occasion to check if all modules repositories have a license.md, a readme.md and eventually a contributor.md (prerequisites)

Also, this will help to show the features and all the work being done on 1.7.

Todo:

• Add the new section with missing modules in the devdocs
• Check if all prerequisites are ok and create relative issues if needed
• Fix the issues

The OSL has been chosen for modules and the way it applies to users and developers is not always clear.

The AFL has been chosen for modules/themes but it seems that the origin of this decision is unclear and at least, not well documented.

Also, some clarification is needed for developers about how to use those licenses, what other licences are allowed for adding third party libraries to core and modules/themes, and eventually how to handle specific use cases.

The PrestaShop legal team wrote a legal notice for the company C-level, let see if we can adapt it so it's possible to publish it as a reference.

It all starts here PrestaShop/PrestaShop#18190 (comment) then I discussed this with @ttoine here #11

I have been working with Prestashop ecosystem for 4 years now in an industrial and professional context.

Because it's a conviction

When I was younger I often heard the quote :

If you don’t do this no one will do it for you.
No one can solve all your problems or fix what’s going on inside your own head

I believed in it 100%, until I discovered the ope-source philosophy. Today I am convinced that someone can solve my problems, but what excites more is the effect that I can solve the problems of others and together we can build very powerful solutions.

Motivations

I work on more than 300 Prestashop stores, I support our clients in their migration process (Pretashop to Pretashop Or Other solutions to Prestashop), in preventive and curative maintenance. So I know the real needs and the daily problems of customers and merchants.

I have been contributing to the Prestashop open-source project for 1 year now, first PR. I decided to contribute because :

• I wanted to motivate others to contribute too : I might be wrong, but I got the impression that part of the community was discouraged with the migration to symfony. So it was for me a way of saying: Come back guys ... Pretashop is not dead
• I wanted to learn and progress : if you look at my last PRs compared to the first ones, you will easily see a considerable progression.
• a way to express my altruistic values and my spirit of sharing
• I wanted to be credible : I wanted to assure our clients and confirm my expertise on Pretashop.(I also wanted @LouiseBonnard to do an article about me : Contributor interview ... but it was less important)

Today I help by contributing frequently :

• discussions with the Prestashop team and contributors
• improvements and new features (BO, FO, CO)
• code reviews
• help community members (GitHub, Slack)

I am very interested in writing technical documentation, tests and especially automation tools for deployment.

Why become a maintainer then?

Honestly, the role of contributor would be enough for me ... and I see this role as a consequence and not a personal need.
I don't really have any particular motivations apart from those already mentioned, in some cases I often feel limited in my role of a simple contributor see for example :

• PrestaShop/PrestaShop#20848 (comment)
• PrestaShop/PrestaShop#18340 (comment)
• PrestaShop/PrestaShop#18116 (review)

Becoming a Prestashop contributor will allow me:

• make reviews and propose solutions directly
• be assigned in the issue that I would like to work
• discuss deeper topics with the technical team and give my vision of the field
• use "merge" button and add labels on issues
• continue to learn and progress

Where I can help?

In a first phase I would like to start with :

Core

• symfony migration
• new features and improvements
• code reviews
• Issues fix
• community help (GitHub, Slack)
• doc

Docs

• improvements
• tutorials on the new architecture and the legacy system
• tutorials on migration strategy and automated deployment pipelines

With great power comes great responsibility

I know how frustrating it can be, but it's my daily life !
I support a team of developers and students in certain projects and I know how to deal with conflicts and disagreements. I will not always agree with you, but I will express my disagreement by respecting the CoC

About me

From Angola, Software Engineer, Open source lover and Lazy hard worker !

Technical skills that may interest you:

• software design and development (web & electronic)
• automation (IaC)
• system Admin (Unix)

Projects with pretashop

Here are some examples "public" projects I have worked on:

• K-way (Multi-shop)
• Cornilleau (Multi-shop +10 shops, Multi-lang)
• Karmakoma
• FC Bordeau
• SFA (Multi-shop (+25 shops), Multi-lang,)
• Compressport (Multi-shop (+9 shops), Multi-lang)
• Tecmatel
• Le geant de la fête
• Golf des Marques
• +300

Languages

Stats

The provided Powerpoint file opens in LibreOffice and OpenOffice, but with style inconsistencies. It would be better if the slide deck were in an open format.

Currently, a few modules have a separated issue board.

To make it more easy to track issues for project management, and to make only one place for users, the good way is to configure the repositories so issues are created in only one place.

This place should be the main repository.

Also, be sure that readme.md and devdoc tells where to open new issues.

I am struggling for a few hours on this problem I will be very happy if you can help me out with this..

I need to make another group besides customers that will get 10% off on all the store

The problem is when I add the new group and I put a discount, the customers from this group don’t see any discount..
When I put discount for all customers it’s working but any additional group doesn’t work.

I know how to make discount for different groups and it works perfectly fine, The problems start with additional groups more then The three groups of visitor guest and customers, and with a catalog discount.
in the functionality of prestashop add groups, after I add a group with catalog discount for this specific group.
When the customer from this group will log in it doesn’t display the discount.

I would like to add screenshot so you understand..
thank you very much

https://screencast-o-matic.com/watch/cr1Q6hVhJJF

Hello!

I'm new over here, I hope you can help me :)

I have a issue with that. My client sells bags. Each bag can be customizable or not. If it is customizable, my client wants to charge an extra fee (+5€).

It's very easy with attributes and combinations to get that, but if I create the attribute 'Customize' with options: Yes / No, the bag generates 1 bag with customize option and 1 bag without customization, when she only have 1 bag.

Is it possible with code fix that? I mean, if a client buys 1 bag without customization, the stock in the bag with customization also reduces by 1.

Thanks!!

I want to be a maintainer. For modules for start, and why not in the core later when I will learn how to git rebase (private joke for @matks ) ;-)

I contribute

• I've already have some merged PR in Prestashop core and modules : http://contributors.prestashop.com/#jf-viguier

I'm a friend of presta
I've lauched the "ecommerce solidaire" initiative with 200 prestashop deployed
In video : https://youtu.be/UVi9_VwLxlo
In the press "le journal des entreprises" :
https://www.lejournaldesentreprises.com/toulouse/article/coronavirus-des-experts-du-e-commerce-aident-les-tpe-creer-leur-site-marchand-493162
I'm vice president of Friends of Presta french association

I'm involved in ps events
I've organized some events in Toulouse about Prestashop

• First Symfony/PS masterclass in France :
  https://lacantine-toulouse.org/8067/masterclass-developer-prestashop-prise-en-main-du-nouveau-framework-de-la-version-1-7-base-sur-symfony
• Conference on Prestashop 1.7 by myself :
  https://lacantine-toulouse.org/7901/afterwork-prestashop

I craft Prestashop websites since 7 years
I own Creabilis Agency in Toulouse, we've done some very customized prestashop websites :
https://www.thierry-aime-chocolatier.com/
https://www.declicfitness.com/
https://www.memecosmetics.fr/fr/
https://www.mgirod.com/17566-flyers-a6.html
https://www.unique-editions.com/150-285-livre-personnalise-au-pays-du-pere-noel.html

twitter : https://twitter.com/jfviguier
linkedin : https://www.linkedin.com/in/jfviguier/

Hello, would it be a good thing to add a area on https://www.prestashop-project.org/ that would

• provide the list of past Public Demos
• provide the schedule of incoming Public Demos and (when it's definitive) the content

What do you think ?

Currently, only employees of the PrestaShop company can be maintainer, with the code review and code merge power.

In order to reduce the bottle neck of the code review / merge and also to give more power to companies with other priorities than the PrestaShop company, it is time to open the maintainer role to other people, outside the company.

my website works in my local server but when i migrated to ovh server i have this error

when i deleted the var/cache content i had these warning
Warning: simplexml_load_file(): I/O warning : failed to load external entity "" in /home/vrqlcrq/www/src/Core/Localization/CLDR/Reader.php on line 152

Warning: simplexml_load_file(): I/O warning : failed to load external entity "" in /home/vrqlcrq/www/src/Core/Localization/CLDR/Reader.php on line 162

Notice: Trying to get property 'parentLocales' of non-object in /home/vrqlcrq/www/src/Core/Localization/CLDR/Reader.php on line 212

Notice: Trying to get property 'parentLocale' of non-object in /home/vrqlcrq/www/src/Core/Localization/CLDR/Reader.php on line 212

Warning: Invalid argument supplied for foreach() in /home/vrqlcrq/www/src/Core/Localization/CLDR/Reader.php on line 212

Notice: Trying to get property 'parentLocales' of non-object in /home/vrqlcrq/www/src/Core/Localization/CLDR/Reader.php on line 212

Notice: Trying to get property 'parentLocale' of non-object in /home/vrqlcrq/www/src/Core/Localization/CLDR/Reader.php on line 212

Warning: Invalid argument supplied for foreach() in /home/vrqlcrq/www/src/Core/Localization/CLDR/Reader.php on line 212
Help me please