RFC: freeze new generators/locales to focus on faker-ruby performance and organization

[stefannibrasil]

faker-ruby has been in a state where there are few bugs being reported. The current open issues are related to code organization and performance.

Most of the work in maintaining the gem has been about reviewing new generators and locales. This makes it really hard to focus on the issues reported above. I don't think faker-ruby needs more generators, in true honesty.

For locales, I think it would be better to focus on adding more translations to the existing locales, and not focus on adding completely new locales.

My suggestion is to only add new generators after there's been a discussion about them in the community. This will allow us to measure the interest and see some traction before we decide to accept the proposal for a new generator.

--

I've enabled Discussions for the project. My plan is to update the guidelines so people need to first create a Poll when they want to propose a new generator or new locale.

(This won't be necessary for updating existing locales - because the existing ones can benefit from more translations/updates/fixes)

After the Poll is created, a new generator proposal will only be accepted if we see some traction (at least 10 votes from the community after 3 months).

That way, we can focus on making faker-ruby faster and easier to use. We can finally tackle some issues that have been open for a while, especially this one.

My proposal is to implement a new feature freeze on January 24th, 2024 to give us room to focus on the improvements.

Could you please let me know if you have any concerns/comments until January 24h, 2024? Once the code freeze is in place, I will update the docs. Happy new year!

[stefannibrasil]

@vbrazo @Zeragamba @psibi @thdaraujo

[thdaraujo]

I agree with creating a poll for new generators, it's an interesting idea.

We run the risk of adding a generator that is only ever used by a single person. We currently have no way of knowing how popular a generator is, so it's hard to deprecate any of them or prioritize the work and focus on the ones that need improvements.

I'm happy that people want to contribute and create new generators, but maybe we can direct their energy to improving the existing code, expanding existing locales, increasing performance, etc.

[stympy]

I like the suggestions here. Splitting the gem as described in the referenced issue could help. I'm just spitballing, but if you left only the basics like Internet, etc. in faker, and then split the more esoteric stuff into separate gems that depended on faker, that might encourage people to create (and maintain) their own gems for random stuff like all the known slug species rather than opening PRs on faker. It seems that Faker::TvShows could become faker-tv-shows, Faker::Movies could become faker-movies, and so on.

Another option would be to move the only the base stuff to a new faker-core gem, have faker depend on that, leave the rest of the faker gem as-is, and stop adding new generators to faker. Then people could create their own gems that depend on faker-core, and if any one of those got heavily used/starred, it could be considered for inclusion in faker.

[Zeragamba]

depends on how much of a breaking change we want to do with this.I'm in favor of splitting into faker-core, as it would open the opportunity to split into more specific gems over time without breaking backwards compatibility while we do so. Heck, if we're following Symver, it could even be done as a minor patch number. edit: -snip-

[stefannibrasil]

I'm just spitballing, but if you left only the basics like Internet, etc. in faker

One idea is to put together a form asking people to share what generators they use most since that's the only way we can know what the popular ones are.

that might encourage people to create (and maintain) their own gems for random stuff like all the known slug species rather than opening PRs on faker

Another option would be to move the only the base stuff to a new faker-core gem, have faker depend on that, leave the rest of the faker gem as-is, and stop adding new generators to faker.

That's a good idea. I will take some time to explore the paths we can take. At the moment, freezing new generators and locales will help a lot with having the time to investigate and put together a proposal with more details.

One idea is to explore the concept of plugins. We keep the ones like Internet, name, etc. and add the ability of adding plugins. It's similar to what you're mentioning -- I'm just proposing the term "plugin" for it.

[stefannibrasil]

depends on how much of a breaking change we want to do with this.

Yeah, that's something that we will need to discuss. I'm gonna focus on putting together a proposal for this.

In the meantime, are you all in for freezing new generators/locales until we decide on that? Thanks for chiming in, I appreciate you taking the time to reply and share your thoughts.

[stefannibrasil]

I opened a PR here updating the docs: #2886

Please take a look and share your review. Thanks!

[sprotty]

I've been looking at a few versions of Faker for different platforms (Java, Ruby etc), and it seems there is a lot of duplication of effort, with some of the ports being very limited. The Ruby Faker library seems to be the best supported, so I was wondering if there was a way to make this the 'root' project and base other platform implementations on it.

I've had a quick look through the project and had some thoughts on how this could happen with with minimal disruption. The generators themselves could be generated from Meta data (this could then be done for any target platform). It would also allow complex generators to sit along side the generated ones (although these would need too be ported to target platforms explicitly). Initially all generators would be like this, but gradually they could be converted so they are described by Meta data.

I analysed the code and approximately 2/3 of the functions could be ported with a script to be generated from meta data, and about 1/2 of the remainder would be trivial to port but would have to be done manually. Some of the remainder could have there logic pushed into the the yml files, making them compatible (some more with a few additions to its rules), the remainder would be too complex to describe in meta data, so would need platform specific implementations.

Any thoughts on this?

[thdaraujo]

@sprotty I believe the Haskell package by @psibi utilizes the data already available in Faker -> https://github.com/fakedata-haskell/fakedata?tab=readme-ov-file#comparision-with-other-libraries

Not sure about other implementations.

[psibi]

That's right, thanks @thdaraujo! The current state of faker-ruby is good enough to be used in other languages as all the required data is the available in the yaml files.

[stefannibrasil]

Survey to get more context on what generators the community is using, and other questions to help with this work is live here: https://app.polling.com/forms/3103cabf-0fad-4669-b753-a5a4a4598eaa/share

Please share with your colleagues! Thank you.