Add adoption guidelines and rework README, fixes #6, #7

dlang-community / discussions

Get in touch with the DLang community

12 stars 1 forks source link

Add adoption guidelines and rework README, fixes #6, #7 #10

Closed wilzbach closed 7 years ago

wilzbach commented 7 years ago

Basically incorporating the feedback from #6 and #7 into the README. Of course this isn't set into stone & can also be improved upon.

rikkimax commented 7 years ago

Currently the guidelines are conflating best practice with how members of the organization should behave.

If the goal is to help maintain codebases which are in use but don't have enough help to keep it going e.g. pulling PR's, then this PR does not address this.

So here is what we are looking at:

What do we expect (as best practice for D code)?
What do you need from us?

A list for best practice (basically what you got already):

Use some form of CI integration
Documentation generation e.g. adrdox via CI integration on push
Don't push straight to repo, fork +PR

A small list for guidelines of members:

Should we pull if no reply after a week?
Can we pull smaller changes like docs if they come up
Do you require a specific set of people to perform maintenance, e.g. specialities or just preference
Do you have any specific instructions for us?
Do you want us to approve PR's from your fork?
Is it not ok for self pulling of PR's?

ghost commented 7 years ago

Can we pull smaller changes like docs if they come up

Allowed without CI,fix obvious typo etc. Readme changes, etc.

Should we pull if no reply after a week?

No for new features. Yes for bugfixes that pass CI. That being said there are cases where a bugfix can be pushed and it breaks something that's not yet tested by the unittests.

Is it not ok for self pulling of PR's?

Ok if approved. This has been already been done latest 2 weeks. The case of "no reply after a week" makes exception (so a bugfix that passes CI).

ghost commented 7 years ago

Also something i like is what's done in the DUB repository: fixes and new features are pushed in new branches directly in the original repository. Are we allowed to make PR with branches on the official repo rather than on our fork ? I think so. It's easier to test the fix or the new feature. Because no need to add a new origin.

rikkimax commented 7 years ago

The important thing is that the guidelines leave the original authors in control, not us. We're here to help maintain, making everybody's lives a bit easier.

ghost commented 7 years ago

leave the original authors in control

Sure for Hackerpilot, but for kiith-sa this strategy is the same as accepting to hit a wall

wilzbach commented 7 years ago

Thanks at @BBasile @rikkimax for your ideas and discussion and I have tried to incorporate your feedback to this PR. As you have seen I'm unfortunately also not that often available and currently our README is nearly blank, so I would appreciate if you pull this if you agree with the main content. You/we can always add new ideas/answers/guidelines to it afterwards (I guess this will be a continuous process as we gain more experience with this organization).

wilzbach commented 7 years ago

wilzbach commented 12 days ago

Hmm ... So I am now taking action and merging this PR as currently the README is almost blank. Please feel free to submit edit / improvements to the README ;-)