Sep 25, 2018 | 3 minutes read
Beginning of any project (especially when we are talking about open source) is extremely entertaining for developer, over the years the fun passes and it is the responsibility to keep your “son” following the path of it.
All projects I started are out of necessity, the awesome-go was no different.
After knowing the awesome-python and seeing other “awesomes” projects I searched for the awesome-go and did not get results. Wanted to do a “simple” project where he had markdown code with a list of legal projects written in go, this in “Jul 6, 2014” with the commit “start environment Awesome for Go”
After many people help the project began to have access and receive contributions. That was the moment I realized I would have to write code to help revise the contributions (dubbed as pull request within GitHub). Maintainers have written test to validate the following patterns within the markdown:
Work that was done manually by the maintainers and the volume of contributions was virtually impossible to revise all.
There are several, but I will talk about what I currently find most complicated (involves very very dedication). I always thought the big challenge of keeping project open source would be to write code, but for many years I believe it was wrong. Today I see that the biggest challenge of maintaining project is to create community, train new leaders, write documentation for new contributors understand and to be new covers join the project.
The awesome-go is no different from other open source projects, just contribute, interact, engage and etc, which will have your space. From now on, I welcome you to the project. Interested in contributing, recommends reading:
The focus has not changed (it is the same), we are a list of go packages, categorized and maintained by the community.
Last year I sent e-mail to some current maintainers go language team proposing to move the repository to golang organization to be managed by the core team, after a few email exchanges they responded to me with some “problems” if the awesome-go was maintained by the golang organization. In a brief summary the awesome-go would go from a list of packages (maintained by the community) to a list of “official packages approved by the core team”, and that not purpose of the project.
As all open source projects the focus is to grow community maintainer, thus bringing new ideas (and diversity) to improve each day the list of packages and agility in reviewing the contributions.
We need to improve the visibility of the site awesome-go.com on Google (SEO), for this we need people with new ideas and willingness to contribute.
All the idea to improve the life of the awesome-go project will be very welcome!
Stay inside:comments powered by Disqus