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



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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]