Re: [BuildStream] Contribution Guidelines, Status of nosoftware subgroup

[Chandan Singh <chandan chandansingh net>]

Hi all,

Thanks for the prompt responses.

Initially I was hoping to report back with a patch but I haven't found
time to finish that yet. So, I wanted to write this message to say
that I am happy to take the action of cleaning up the nosoftware
subgroup.

I have started with the contribution guidelines first. Once I have
migrated those, I will look at what else is there and what needs to
happen with those. I will get back to you once I have a plan for that.

Thanks!
Chandan

On Thu, Apr 9, 2020 at 6:38 AM Tristan Van Berkom
<tristan vanberkom codethink co uk> wrote:
> Hi Chandan,
>
> On Wed, 2020-04-08 at 23:34 +0100, Chandan Singh wrote:
> > Hi,
> >
> > I was looking at our contributing guide to add some specifics on issue
> > reporting, which is when I realized that our contributing docs
> > (https://docs.buildstream.build/master/CONTRIBUTING.html#filing-issues)
> > refer to a policy guide in a separate "nosoftware/alignment" repository
> > (https://gitlab.com/BuildStream/nosoftware/alignment/-/blob/master/BuildStream_policies.md).
> >
> > I personally found this rather odd and I don't see why these instructions need
> > to live in a separate repository. In fact, I was thinking about making this
> > section more prominent, and move out of the Contributing section to the
> > top-level index. But, that's a separate concern.
> >
> > The information in the nosoftware/alignment repository is certainly out of date
> > now given that it hasn't been updated in over an year. In my opinion, we should
> > some of this content to the main contributing guide, perhaps in a more condensed
> > form. The current guide seems very process oriented and focuses too much on
> > labels, assignees, statuses etc. I think we can simplify most of this since we
> > should aim to keep the barrier to entry for contribution low. How do folks feel
> > about this?
>
> Definitely let's simplify this.
>
> This all comes from a desire to manage progress on issues at a project
> scope, which I think is a strange and burdened process for a FOSS
> project.
>
> My position on this remains that the process for using our issue
> tracking and patch submission should be as simple and unburdened as
> possible.
>
> > This specific question aside, I am also curious about the nosoftware subgroup
> > (https://gitlab.com/BuildStream/nosoftware) in general. Since none of the
> > repositories there have been updated in quite a while, I wanted to ask if
> > anyone is maintaining it currently?
> >
> > If so, I think we need to document what each repository is supposed to do. At
> > present, they seem to have a weird combination of pdf reports, status updates,
> > shell scripts and weirdly enough our beloved BuildStream Beaver.
> >
> > If not, we should probably move some of the content to the main repository or
> > the website, and archive the rest.
>
> +1 to retire the nosoftware subgroup in general.
>
> We would want to move some things to the BuildStream repo and some
> perhaps to the website.
>
> I suggest when doing this we consider:
>
>   * Is this content specific to a BuildStream release/version ?
>
>     If so, it's useful to have this revisioned with BuildStream code,
>     technical documentation and guides for instance can later be
>     indexed by BuildStream version which is useful.
>
>   * Is this content specific to the BuildStream repository ?
>
>     If so, it's convenient to have this in the BuildStream repo, for
>     the purpose of minimizing fragmentation.
>
>   * Is this content general for any repositories under the governance
>     of BuildStream ?
>
>     If so, it's probably best to have this separate, in the website
>     repo.
>
> Does this make sense ?
>
> Cheers,
>     -Tristan