To me it makes sense that core should also be able to merge commits to the manual - e.g. when something in core changes, there should sometimes also be a matching change to the manual. What do you think?
- yes
- no
0 voters
1 Like
I don’t think this is a good idea. Just because it might be convenient does not mean people have actually earned the commit access. Just because you have knowledge of ruby and core does not mean you know jekyll, markdown and how our website is structured.
I think you should earn commit access to a repo by showing experience in the particular domain or codebase.
1 Like
I agree. Just because you don’t have commit access doesn’t mean you
can’t submit PRs to the website, nor review prs modifying existing
content. Nor does having commit access guarantee a particular developer
will do those things.
Justin
2 Likes
I think I would be in favour of this if our docs were somehow separate, but as it’s structured today, I think I agree with Timo. Updating the docs/plugins/etc does makes sense, as you say, but there’s a lot of other public facing stuff in the website repo.
Given that the site is built via Jenkins anyway, there’s nothing stopping us restructuring how the docs are maintained/built - it should be pretty easy to have a Jenkins job which can detect changes in 2 (or more!) repos and git clone both of them … This might also give plugin owners more autonomy too.