Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Problem: The documentation is out of date #376
This is an attempt to create a list of all assets and info on the LibreTime manual at libretime.org that need to be updated as they refer to an old version of 2.5.1 or we have changed the features etc.
Pages in need of update
Stuff missing from Manual
changed the title
Problem: The documentation is outdate and has incorrect info and screenshots
Dec 1, 2017
referenced this issue
Oct 12, 2018
@frecuencialibre I checked the things you mentioned off.
To be able to do such tasks yourself you need write access to the repo. Currently our process for this is adding you to the @LibreTime/maintainers group. If you are willing to take on the position of being a Maintainer I would be glad to do so as you have clearly demonstrated the following:
Please take a look at the C4 contract to decide if you can see yourself becoming a Maintainer.
If you're ok with this and @Robbt chimes in and gives his ok I'll escalate your rights.
Thanks Lucas, yes, I would like to chip in as a maintainer. My availability may be inconsistent, as I sometimes have to deep dive into paid gigs and community commitments, but I am planning to stick with this project in order to provide a long-term solution for my local community radio.
I'd probably focus on
In general I can tell you've put a lot of work into setting this up well as a collective effort, and i like what i'm reading 1 2 3. I personally try to balance my obsessive-compulsive tendencies, which are often helpful in programming, with speed and real human interaction ;).
Yupp, we didn't get around to implementing those yet.
I don't understand this as an issue being mandatory for a later PR. The MAY part says it's perfectly ok do directly do a PR.
AFAIKT this isn't set in stone, in fact noone has merged their own PR after waiting only 2 days. It's more like we wait for 2 months before we merge as described in C4.
I support this but it does seem like an edge case that we should only invoke in extreme cases. We can also decide not to merge an affected PR. I see it as a loophole to accept PRs and fix them later. Maybe we should ask the ZMQ community as initial authors of the C4 for some guidance here.
You can switch to their forks branch to test them, being able to maintain multiple personal forks as part of development is important.
edit: I really like (and fully support) what you are proposing as your focus !!!
Hola @frecuencialibre! crazy coincidence!
not sure, I was kind of waiting to have a draft or smtg to start. So if you know where to start, lets do it...
sweet, let's try to meet for sure!!
added a commit
Nov 25, 2018
I am confused about the slightly legalese wording of the C4 guidelines, so if someone would clarify, I have a pile of doc PRs to submit.
It's a fairly accepted practive to make any and all changes on branches created for that purpose. For example, i want to make a PR on the docs to help in the effort, I'd make a branch (in my fork of course) called 'docfixes'. Make my fixes using small atomic commits as I go, push the branch to my fork then do a PR against the issue. The maintainer would then pull my branch, test/review, merge, and delete the branch,
Does the above C4 guideline say NOT to do that?
great! welcome @nikmartin !
the workflow that you've described looks correct to me. my understanding of that phrase from the C4 document is that branches in our forks are to be used for the creation of PRs, but that we're not creating branches here in this main LibreTime/libretime repository - PRs should "pointed" to the master branch in this main repo. Other maintainers would know more, but i can confirm that PRs such as #608 are perfect!
Yeah I think @frecuencialibre has the right interpretation. We don't want the main repo to be littered with topic branches and instead keep them on personal repos and then merge them when they are complete. I think the intention was more important for a project like ZeroMQ which the C4 was developed for but the basic idea is sound. Keep the master repo clean and merge things when they solve a specific problem. So yeah the way you did it is right. I think it's generally called the Pull & Fork approach. If multiple people want to collaborate on a feature a WIP PR is posted and people can push code to the branch on the individual repo. At least that is how we have done it thus far.