Evan, This is a great idea! I wonder, more generally speaking, if we could move CONTRIBUTING.MD into the wiki on Github and turn it into a one-stop shop for getting started on the contribution process? It would be great to make the contribution on-ramp easier, and having a clean wiki we can organize & edit quickly without the PR process would go a long way in that direction.
On Wed, Apr 28, 2021 at 1:25 AM Evan Rusackas <[email protected]> wrote: > Greetings everyone! > > Inspired by conversations in the community, and by a similar process > beginning to take shape in Design Guidelines on the wiki (see > https://github.com/apache/superset/wiki/Design-Guidelines) I’d like to > propose following a similar process to begin organizing and compiling a > collection of coding style guidelines and best practices (preferred > patterns) on the Wiki. > > Sections of coding style guidelines and best practices will be written up > as Github Issues, with their wiki-compatible markdown as the content of the > issue. They will then be floated here on the dev@ list for lazy > consensus. Discussion/questions can be handled here or on the Issue itself > as needed. If/when lazy consensus is reached (i.e. there is no > objection/contention) then the markdown will be moved to the appropriate > page(s) on the wiki. > > This content will be partly a result of previously voted-in SIPs, and > partly some sensible/modern patterns and practices that already exist > within the codebase. Pointing out these patterns and anti-patterns will > likely help new developers figure out which approach to take when building > something new. > > To get ahead of the question, it would also be possible to do this in a > markdown page (e.g. CONTRIBUTING.md), but the Wiki is more of a “living > document” and doesn’t require the process of reviewing/merging PRs. All > committers/PMC members have access to touch up these pages as needed to > make sure they stay up to date and well-organized. Having these on the wiki > also means we can quickly iterate on and adapt this process as needed. > Since it doesn’t touch the codebase directly, I figure probably doesn’t > warrant a SIP. > > So… I seek lazy consensus on this idea. If it goes through, then I’ll > start floating some easy/lightweight proposals to further establish this > process. > > Thank you for your time and attention, > > -e- > > Evan Rusackas > ( he | him ) > Frontend Lead > Preset | preset.io >
