Discussion on how/when to merge fonts into the master branch

[Thomas-Boi]

Hey @amacado,

I think that we should discuss on how we are going to merge fonts into the master branch from now on. Now that we have the build system, we can do batch updates instead of single changes. However, this means that we might have conflicts when merging or we might repeat fonts already added.

Perhaps we should create another readme for merging rules. This would be useful for future collaborators who would like to help us out. Beside that, we also need to work out a way to communicate who's merging which font/PR.

For the readme, it should list out things like:

• How to add new icons to the devicon.json
• What to do before pushing the changes: make sure files are in the icons folder
• Possible issue (the task failing for the first couple times but work if you re-run it)

For the communication over which who's doing which PR/fonts, I think that we can use the GitHub Projects tab. I created an example board that you can check out and try. We can customize this to address issues as well.

Let me know what you think :)

[amacado]

I support your ideas of defining a new workflow and enhancing the readme with information on how to collaborate. Regarding this topic I would propose to introduce a simple gitflow, where we do not merge feature branches (new icons) directly into the master branch but instead a new branch called develop. This would solve multiple problems:

1. Currently our build action not working properly, because the master branch is write protected (if we would perform this action on a new non-protected develop branch this should work

(see https://github.com/devicons/devicon/runs/1090416932)

2. More resilient release: We can test changes in the develop branch before releasing a new master version (when we integrate this in npm, what is on my list (npm release #288), this would improve our quality

See this image of gitflow-workflow:

(image taken from https://m.infos.seibert-media.net/Productivity/Git-Workflows+-+Der+Gitflow-Workflow.html)

I think I can work on this, if you approve, at the upcomming weekend, what do you think @Thomas-Boi ? :)

[Thomas-Boi]

...we do not merge feature branches (new icons) directly into the master branch but instead a new branch called develop

I think that's a good idea. I think that will also fix the many failed build there were when people do PR :)

I can add the new rules to the CONTRIBUTING.md then (commit to develop instead of master, guide to use the build script). Besides that, I'd also like to get your feedback over how maintainers should communicate which tasks need to be done.

[amacado]

@Thomas-Boi I was busy last weekend so sorry for the delay. I hope to get up the "develop" branch this evening. Besides that: What do you think would be the improvement using the projects tab (i haven't worked with it yet)? Does the pull request/issue "assign to" method does not fit or is insufficient?

[Thomas-Boi]

At the time that this question is created, I forgot that we as collaborators can assign tasks. I think that's a good enough way for us to divide PRs for merging.

So from now on, do we tell font contributors to create PR to develop instead of master? Or do we pull their branch to our local machine, merge into develop then push it to remote?