Comments (7)
@sshine Thanks for this. A few thoughts.
- I imagine there will be an initial flurry on improving docs, but then I think most PRs will touch one
languages/xxx
. Some will also touchreference/
, where clashes may emerge, but I imagine this will be rarer. So I hope merge-conflicts are rarer than might be expected right now. - I'm totally fine with tracks making their own rules about this, as long as there is a review step in that. So if JS wants to have a rule where a senior maintainer approves every PR before it's merged (which sounds sensible to me) then that's fine. But another track might not have the firepower for that, and are more willing to immediately move to something more akin to egalitarian approach.
- At least at the beginning, I would rather @ErikSchierboom is assigned often to provide guidance. I would generally rather I wasn't assigned unless something needs a co-founder-level opinion, because having me as a blocker on things slows it down for everyone.
- If senior maintainers (e.g. the three of you) want to just go round being helpful, that's great, but in many ways it's much better to give the newer maintainers the opportunity for cutting their teeth reviewing PRs etc.
One final thought, there are maintainers working on multiple tracks. It is important that if not consistency across tracks, there is documentation that those maintainers can refer to. So I would like us to have a Guide To Contributing (CONTRIBUTING.md?) which lists the global rules (e.g. everything needs a review) but also points to a common location in the langauges/xxx sections where track-specific rules might apply.
from concepts.
Just looking at some of these PRs, we also need PRs that don't touch 100 files across repos. They get merged too quickly and there are errors in them. e.g. #90
If big changes need to happen across the repo, these should be pre-coordinated with Erik I think.
So that needs to go into a policy too.
from concepts.
One final thought, there are maintainers working on multiple tracks. It is important that if not consistency across tracks, there is documentation that those maintainers can refer to. So I would like us to have a Guide To Contributing (CONTRIBUTING.md?) which lists the global rules (e.g. everything needs a review) but also points to a common location in the langauges/xxx sections where track-specific rules might apply.
Yes please.
from concepts.
It'd be neat if we could just say "code owners approve and merge", but then I might need to approve my own pull requests
Maybe a little variation on this? If no single person was explicitly assigned, code owners should approve and merge. However, if I as a PR submitter want a specific person to review and merge the PR, I then request a review from that person (as opposed to the code owners).
Does this make sense?
from concepts.
I Have been merging things last night that weren't really in my domain just to avoid merge conflicts as much as possible while all the maintainers start adding their data to the maintainer files.
Generally I intend to stick to merging only Go-related stuff.
Approving PRs I think is something everyone is welcome to do.
from concepts.
I want to have a say in all things javascript
and typescript
and in general I think current maintainers should be reviewing prospect maintainer contents. I think that the other stuff: "typos etc" can be merged by anyone who has triple-checked them.
from concepts.
I believe this issue becomes obsolete after we explode the v3 repo back into track repos.
from concepts.
Related Issues (20)
- [Elixir] The `try-rescue` vs `try-rescue-else-after` problem in the concept tree HOT 10
- [Elixir] Implement new Concept Exercise: `file`
- [Elixir] Implement new Concept Exercise: `dynamic-dispatch` HOT 3
- [C#] attack-of-the-trolls - improve exercise
- [Common Lisp] Improve Concept Exercises pronoun usage.
- [Common Lisp] Improve Concept Exercise Generator: remove after.md template and generation
- CI should run only on files affected by a PR HOT 4
- [Python] Update Exercises Table on `../python/exercises/README.md` HOT 4
- [Python] Improve Concept Exercise: lists HOT 5
- [Elixir] Add missing "name" field to config.json HOT 4
- [Elixir] Improve concept exercises by ensuring that single tests are self-contained HOT 3
- [Rust] Improve Concept Exercise: numbers
- [Common Lisp] Improve Concept Exercise: lillys-lasagna-leftover
- [Common Lisp] Improve Concept Exercise: key-comparison
- [Common Lisp] Add CI for validating the track HOT 2
- [CI] Simplify pushing Docker images for tooling repos HOT 2
- [Common Lisp] Concepts need introduction.md files
- Create concept introduction documents HOT 1
- [WIP] Big Bang TODO List HOT 9
- The master branch will be renamed to main HOT 1
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 concepts.