RFC - Facilitating code contributions

[Vadorequest]

Right now, non-documentation contributions are a bit tough to work with, because Ci isn't configured on contributor's forked repository, and I don't see another way than making my own branch (created from the PR's patch) and push it on NRN repository.

An alternative might be to allow contributors to this project, but I don't really see better alternatives, and it's still a bit too cumbersome for newcomers (and for me).

Are there good OSS practice about that?

Example: #54 PR had to be imported as #56 to run CI, in order to check if the PR had any positive impact on the bundle size.

[thiagodebastos]

If there are any pointers on what I could to to contribute in a way that would make it easy for you, I'd appreciate it :)
As a first contribution, I would like to give switching out Bootstrap/ReactStrap for chakra-ui as suggested in issue #344.
Let me know, as I have some time at the moment before starting out a new contract soon.

PS I absolutely appreciate the work you guys have put into this, and the initiatives you are involved in! It gives me hope :)

[Vadorequest]

@thiagodebastos Awesome! Thanks for your interest, I'm glad you like what you've found here! 😉

Regarding contributing, I'd love you contribution on #344.

The main issue about contributions is that it's a "raw" thing yet, there hasn't been a lot of non-code contributions so far, or small ones. I don't think the DX on contributing is great, but I'd love to improve it.

As a high-level, here is how NRN works:

• There are two main presets (v2-mst-aptd-at-lcz-sty and v2-mst-aptd-gcms-lcz-sty)
• All changes are shared between both presets, through cherry-pick (except for changes that are specific for one preset, such as Airtable/GraphCMS-based changes)
• All PR are deployed and tested automatically through GitHub Actions (CI), but it doesn't work on forks 😢 (unless configured on each fork, individually)

I think migrating from Ractstrap to ChakraUI is a good contribution. But maybe what NRN really needs is to improve the DX regarding contributions, that might lead to more contributors and would be more beneficial on the long-term.

Maintaining two presets is "hard" for me (it takes time), and it requires knowledge on how both presets work and what are the differences when applying changes shared by both presets. There have been requests about adding more presets, with different technologies but I've never done it because it would slow me down even more and would make it harder to make changes (because it'd take more time, mostly).

[RFC] Layouts

Recently, I re-thought about this "presets" thing. While I like the idea of having multiple "presets" of different tech to choose from, it's really hard to maintain and expand.

I've been thinking about using "Layouts" instead. Where a preset (or part of it) might live within a layout. Concretely, we could have a layout that uses Airtable to display some pages, and another layout that uses GraphCMS to display some pages. And we could have a layout with authentication support.

There wouldn't be multiples presets, but instead there'd be layouts. All the code would live in a single branch. So, there would be 2 branches:

• main (default)
• gh-pages

This would make it much easier to bring one feature (no cherry-pick for all presets), would make it more obvious about the GitHub config (default branch would become main, instead of gh-pages), people who use NRN as a boilerplate could more easily bring in new commits/features and compare their fork to the source (when you want to pick only a few selected changes). I see a lot of advantages.

One big consideration is that I'd need to choose one branch were to start from (one of the preset), and people who've already used NRN as boilerplate would lose the git history and the ability to sync changes. (I'd likely use v2-mst-aptd-at-lcz-sty as main, since that's what's the most advantageous for my company, considering we have 2 products using it)

Another consideration is that Next.js is working on a "layouts" feature, too. And I don't know how that might affect things.

Contributor DX

But, this doesn't really solve the DX contribution issue. It makes it easier because it's possible to contribute to one layout without changing others, but it doesn't solve the CI issue (where each contributor need to configure the CI on their own fork, otherwise tests aren't executed).

Do you have any experience with those kinds of things, by any chance? What do you think about all that? 😄

[thiagodebastos]

Thank you for this 👀. I'll be having a think about it.
I don't have experience myself, but have worked with others who have (eg the creators of @parcel-bundler and the folks over at @atlassian and @Thinkmill) who were always facing issues that seemed to be very much related to this. I will get in touch with them and hopefully they can help!

[Vadorequest]

If they want to get in touch with me, they can contact me on Twitter directly https://twitter.com/Vadorequest or in this discussion :) That'd be awesome!

[samuelcastro]

@Vadorequest The only problem of having one single branch is that you'll need to add all dependencies, that might not be a big problem if the difference is just GraphCMS/Graphql vs Airtable/Rest, so I think that would be ok.

In general I'm ok with this approach, I'll lost the history but I think the benefits will be worth it.

For contributors I think you should include a few maintainers as github users that will be actively adding features, fixing bugs and reviewing others PRs from the community.

[Vadorequest]

Yeah, there is that, it'll make the app bigger. It might also be more complicated to remove all the stuff we don't need when using it as a boilerplate. I don't see any "perfect" solution.