Thanks @ragini. As discussed, adding below point as you asked me to share here.
Can we consider design documentation from the start? Why I am telling is due to below - New joinee can understand the software more easily than deciphering the code - It will help in incremental enhancement - Design helps to understand not to break core attributes of software we develop - Design will help review and allow quicker approval - It will help to refactor code later. It is a hard fact that most software needs refactoring over the time and it must be done when needed. Can we make best practice to mention the design on each PR so that we can incrementally build a good design documentation? Warm Regards, Deepak On Sat, 17 Jul 2021 at 15:28, RAGINI <[email protected]> wrote: > > > > We kick start our Community meets beginning today. > > > > Date: 2021-07-17 > > Time: (UTC+0000) 0800 - 0930 hrs > > > > https://strikr.io/community/meets/ > > > > The focus of this meet is to invite all interested folks for a quick > update. > > > > - what is the road ahead > > - what are the upcoming activities > > - who all are we reaching out to in the free software community > > - action items > > > > > Hello, > > Today's discussion summary: > > Please add your thoughts and points, if I have missed any. > > > * Update website for git, and codeberg practices > - prefix every repo with strikr_ > - support/strikr.md in every repo > - README.md will always contain git clone over SSH instruction > > * All documentation about the projects with be on the website > > * defect tracking system > > * template for commit format > > * contributor guide navigation pane on website > > thanks > Ragini >
