Darktable: Move User Manual into its own repository

Created on 1 Apr 2020  路  13Comments  路  Source: darktable-org/darktable

We should move the user manual into its own repository so that others can be given commit access, hopefully boosting contributions to the user manual. The original idea is from @houz

I'd be happy to be the point man on this repo.

controversial no-issue-activity

Most helpful comment

Here is how I see it: having the manual in its own repo has the benefit that the barrier to actually build it and thus contribute is reduced. currently you need a fully working dev environment to compile dt just to be able to build the manual. That is insane. And the manual is ignored by many devs anyway, no matter in what repo it lives. Also, in general we don't release the manual together with the sources, but it takes quite some extra time until it is updated. That leads to the situation that we tag a state as released that is not really the final manual.
Having a usermanual repo also allows to give out commit rights more freely.
So I see no point in having the manual inside the main repo but several advantages of having it separated.

All 13 comments

I don't agree with that. It mean more work for more people. We need to tag and create branches in another repo for each release. And in any project I have worked on, if the documentation is not with the main project it gets slowly forgotten and get less attention.

I agree with @TurboGit especially on last sentence: "if the documentation is not with the main projet, it gets slowly forgotten and get less attention." Just see the website: it's especially @TurboGit who update the site when a new darktable is release. Many people think of this main repository but not others. And main repository of course doesn't give commit access but it remains possible to propose pull requests. I only work on CSS parts (and had contribute a little on manual, especially french translation) and as it's few commits, pull requests are ok, it also let other people correct and help improving manual parts proposed.

This is more needed to help on making translation easier and faster: #4177

While I agree, that splitting documentation generally tend to cause it to be forgotten, but in darktable's case it lags behind already, so this argument IMHO doesn't hold well here. To me creating a new repository looks like a good idea to try. You can always merge documentation back into the main one.

Well people not cloning current repository to update the documentation won't clone another one just because that's another one. I don't see the point. As @Nilvus as stated, the best option currently is to see #4177 come to reality.

I'm working on #4177 already; it is a tremendous amount of work. First part of it should be done this week.

On April 1, 2020 12:29:51 AM PDT, Pascal Obry notifications@github.com wrote:

Well people not cloning current repository to update the documentation
won't clone another one just because that's another one. I don't see
the point. As @Nilvus as stated, the best option currently is to see

4177 come to reality.

--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/darktable-org/darktable/issues/4588#issuecomment-607083040

Here is how I see it: having the manual in its own repo has the benefit that the barrier to actually build it and thus contribute is reduced. currently you need a fully working dev environment to compile dt just to be able to build the manual. That is insane. And the manual is ignored by many devs anyway, no matter in what repo it lives. Also, in general we don't release the manual together with the sources, but it takes quite some extra time until it is updated. That leads to the situation that we tag a state as released that is not really the final manual.
Having a usermanual repo also allows to give out commit rights more freely.
So I see no point in having the manual inside the main repo but several advantages of having it separated.

I still don't agree. I do care about the documentation, when I see documentation PR I ask some native people that have proposed to do proofreading to review. This is because when I'm on the GitHub repo I do see the PR, I certainly won't like having to have another GitHub page open to check if PR are there and comment if necessary.

But you don't have to be the only one reviewing and merging...

On April 1, 2020 9:50:03 AM PDT, Pascal Obry notifications@github.com wrote:

I still don't agree. I do care about the documentation, when I see
documentation PR I ask some native people that have proposed to do
proofreading to review. This is because when I'm on the GitHub repo I
do see the PR, I certainly won't like having to have another GitHub
page open to check if PR are there and comment if necessary.

--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/darktable-org/darktable/issues/4588#issuecomment-607365432

Sure, if you mean no one will look at the PR fine! :)

I do want to look at them, as I currently drive the project I find very important to keep in touch with the documentation work. And I suppose this is true for all Devs.

Sure, if you mean no one will look at the PR fine! :)

I said this in the original post on this thread:

I'd be happy to be the point man on this repo.

This issue did not get any activity in the past 30 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

Seems like there is no interest in this.

Was this page helpful?
0 / 5 - 0 ratings