Update with up-to-date screenshots
Hi @Feichtmeier , can this issue be done by someone outside? I don't see the "help wanted" label here but this seems to be the most possible to me..
Wow sure! @dvkndn
I would love help there!
Can you update the wiki with pull requests? I am note sure :thinking:
It's possible but not really straightforward for non-member of the repo: https://gist.github.com/larrybotha/10650410. It requires more work from you (than merging a code PR) :(
Another solution is to have the readme/docs/wiki as source code of a website (I mean like putting it in "docs" and host it with github pages).
Which one do you prefer? Or do you have other suggestion?
@didrocks could you share your preference concerning @dvkndn 's options to update the wiki?
I don't really have a strong preference between the two as you will be the one interacting the most with it. Feel free to thus use the second git repo for wiki (but with manual merging in git then) if you feel it's better for you.
The github hosted page is also a nice alternative, (but it means you need to convert the wiki page and merge them into the repo) as there is then a single repo.
Pick the solution you prefered solution then! :)
use the second git repo for wiki
I think if the wiki (which is a git itself) is supposed to be changed only by 1 or 2 people then we will be fine with this. Otherwise, the manual merging process will be unnecessary complex.
but it means you need to convert the wiki page and merge them into the repo
I could do this for you guys to review in a week or two. It's perfectly fine for me even if we end up not going with this direction.
I think if the wiki (which is a git itself) is supposed to be changed only by 1 or 2 people then we will be fine with this. Otherwise, the manual merging process will be unnecessary complex.
This has been the current workflow indeed (and actually, most of the work has been made by just 1 person). However, this way we make very hard contributing to the documentation which is also important.
For the first approach, it looks pretty good for vscode-wiki: https://github.com/Microsoft/vscode-wiki
This means many people can contribute to the wiki (which will be hosted at https://github.com/ubuntu/yaru-wiki for example) via PRs. After a few weeks one of you guys (Yaru's team) will sync the wiki.
It seems that the syncing would not be too difficult because it's only a fast-forward pull from: https://github.com/ubuntu/yaru-wiki.git to https://github.com/ubuntu/yaru.wiki.git, while all the collaboration work happens at yaru-wiki only.
In other words, the procedure should look like:
origin remote pointed to yaru.wiki.gitpublic, at https://github.com/ubuntu/yaru-wiki.gityaru-wiki repo onlymaster of yaru-wiki should reflect the upcoming changes to yaru.wikiyaru-wiki/master (the public remote) into yaru.wiki/master (the origin remote) and push it to update the actual wikiI fear that having two publicly available repos will cause many misunderstandings
@madsrh @clobrano
Personally I don't feel very motivated to update the wiki
Now after the refresh, is there anything needed besides border-radius, icons, button/entry/headerbar padding and our palette? (Which is reviewed by @clobrano it seems https://github.com/ubuntu/yaru/issues/1522 )
We could also just remove it if you are not emotionally attached to it
Updated the Wiki:
Most helpful comment
I think if the wiki (which is a git itself) is supposed to be changed only by 1 or 2 people then we will be fine with this. Otherwise, the manual merging process will be unnecessary complex.
I could do this for you guys to review in a week or two. It's perfectly fine for me even if we end up not going with this direction.