Hi
You can easily edit the docs online on github, just selected the
documentation file, and click the edit button and it has an in-place
editor, and when you save it creates a PR.
When you do so, then on top of github you should see something along
the lines of
You’re editing a file in a project
>By the way, at the time of moving the docs, there were discussion about this.
This may very well be moot, or rather closing the door after the horse
has bolted. However, I wasn't active at that time.
Plus my experience with such matters is that as I'm not a committer I
don't really get a say or c
You won't have to wait for a new release of Camel to see the site updated. The
documentation will go live, as the site of confluence was.
In that way you'll have the actual Snapshot documentation always updated. Once
we released a version, the documentation will be freezed as that version docs.
Funny that, I never had any problems editing the wiki. Not that I'm
not endorsing the old tooling - it could have have been much improved.
However, despite not being the most pleasant system to use it didn't
prevent me from doing the work. What's more any edits I made would
show up on the wiki with
I don't know what it is your problem with PRs. Camel is a project where all the
PRs are processed in small amount of time and also we aren't pedantic. All the
PRs are generally accepted and merged in a few days. There is no need for
relaxing about PRs.
Also on confluence, we don't have any kin
The only thing to consider here is that having a site separated from repo with
docs never really worked and it's ALWAYS out of sync.
Inviato da Yahoo Mail su Android
Il ven, 19 gen, 2018 alle 2:00, Paul Gale ha scritto:
>I generally agree that the documentation should be part of the code o
>I generally agree that the documentation should be part of the code otherwise
>it is out of alignment.
If by 'alignment' you mean that the doc is correct with regard to the
source it shipped with can be inferred because they came from the same
repo/commit? If so that doesn't make sense to me.
E
>> No, it would not. It would require a pull request.
A committer can commit without approval, no? That's the scenario I was
referring to in the case of documentation. At no point in the old
scheme did an edit require approval via a PR.
>Take a moment and actually look at https://github.com/apach
Paul,
One of the hardest aspects of using Camel is the ability to read the
documentation. We generally use “pair-reading” to interpret unfamiliar areas -
reviewing the examples, tests and source code are more productive. I generally
agree that the documentation should be part of the code othe
> To have that same ability in the new scheme would require committer
rights.
No, it would not. It would require a pull request.
> if they're accepting said requests by reflex then they're not adding
any value so why have them in the loop
They're not. I don't think I've ever seen anyone on
Trust me, I have no love for Confluence as a product. However, even
with only editor rights I could work completely autonomously when it
came to editing the documentation. The ease with which I could update
the documentation made me all the more willing to do so, even for
simple typos and reformatt
Pull requests are still a thing, right? ;)
Kidding aside, the GitHub pull request and review process seems highly
preferable to fighting the wonky Confluence platform, especially since
it gives the community a chance to chat about proposed changes before
they're merged.
What about that is co
Brett,
Thanks for your response.
You have confirmed my worst fears about the documentation solution. Oh
well, all those future edits I had in mind, gone.
Thanks,
Paul
On Thu, Jan 18, 2018 at 4:55 PM, Brett Meyer wrote:
> Hey Paul, I asked the same question a couple of weeks ago -- Claus remind
Hey Paul, I asked the same question a couple of weeks ago -- Claus
reminded me about the move to asciidoc in the central repo:
https://github.com/apache/camel/tree/master/docs/user-manual/en
However, we might consider at least adding a note to the tops of the
current Confluence docs (assuming
14 matches
Mail list logo
