Comments (10)
To put my 2 bucks in the jar:
- Every PR must have at least 1 non-contested approval from another Minetest-Docs team member (other than the PR author) to be merged
- Have useful, scoped commit messages. Such as:
vector - clarified metatable function usage
- If a PR branch falls behind
master
prefer rebasing PR branches if it can be done cleanly, use a merge commit otherwise - Commits can be renamed before merge for clarity while the context is fresh
- Prefer not squashing messy PRs into one monolithic chunk. Rather, squash specific commits together if applicable
from minetest_docs.
"Our one policy is not having a policy"
from minetest_docs.
a empty policy? hardly seems useful
I was just trying to get the discussion started. But if you want my proposal:
- Squash if the history is messy;
- Create a merge commit if it's not
from minetest_docs.
To add to that, it would be beneficial to work on making good commits that don't need to be squashed, since this is a learning experience for me and maybe for you too. Forming good habits helps us develop efficiently, and shows that we care about the project.
My suggestions are:
- keep the changes in a commit directly related to a single goal
- review your changes before you commit them;
git diff
is your friend - keep commit messages brief, and do not capitalize the first letter
- if you need to explain more, put it in the body of the commit
While writing this document, I followed the plain English practices Benrob shared with us in the IRC channel. You can read them here: https://www.plainenglish.co.uk/how-to-write-in-plain-english.html
from minetest_docs.
@benrob0329 I think that is an extremely counterproductive idea – in fact, I think it is the worst proposal regarding Minetest documentation I have read so far. I have seen a lot of PRs in a variety of projects (first of all, Minetest) that have been neglected for weeks or even months only to be accepted. IMO automated closing of tickets or PRs based on how long they have been open is one of the most toxic things that a project can do.
I suggest to only close abandoned PRs once a replacement PR is created or they are no longer deemed necessary.
from minetest_docs.
Our goal is to try to get PRs merged if beneficial, but if they die unfinished and no one has time to then they shouldn't sit around hopelessly. It's also not a matter of how long it's been open, not at all. It's how long they've been neglected by the author(s). Being closed is also not a rejection, it's saying "this isn't open for merging at this time". If a PR is rejected then that's a whole 'nother thing entirely. I think that we should be very willing to re-open PRs if they become active again and see progress, and that contributors should feel open to request a re-opening at any time should they return to it.
from minetest_docs.
a empty policy? hardly seems useful
from minetest_docs.
We probably need a policy for when to close PRs as abandoned/stagnant. I'd argue that if a PR sits around with no activity from the author(s) for 2 weeks, it aught to be closed until the author(s) request a re-opening.
from minetest_docs.
I agree with the policy presented by benrob. (aside from a delay till the formatting pr is merged). [suggestion] additionally all closed prs should be fine to reopen unless labeled with something like rejected/wont fix/etc label
from minetest_docs.
I guess we have informally agreed on how to merge PRs anyway. @GreenXenith can you disable merge commits?
from minetest_docs.
Related Issues (20)
- Build instructions are missing HOT 4
- CSS for generated HTML uses Unicode Private Use Area characters, makes ugly boxes HOT 6
- Document pointed things HOT 1
- Config Template Blocked by Safe Mode HOT 2
- Document profiler HOT 3
- Create comprehensive "what is where" source code overview HOT 1
- Document translation options
- Configuration documentation & recommendations
- Add guides
- Missing "getting started" page HOT 1
- `physical` default appears to be `false` HOT 1
- Sprint 1 HOT 9
- Template is overly verbose and at times misleading HOT 1
- ItemStack doc doesn't document item strings properly
- `set_player_privs` footguns
- Update note about texture modifier memleaks HOT 2
- Relicense to CC-BY-SA (3.0/4.0?) HOT 12
- Document the common pitfalls HOT 2
- Future of this project HOT 8
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from minetest_docs.