Merge pull request #224 from emmanuel-ferdman/main

fix broken references

.github/contributing.md

@@ -13,7 +13,7 @@ These tests typically run via Github Actions, but it is also easy to run them lo
 on your development machine.
 
 > :bulb: the integration tests do not clean up afterwards. To avoid interferences
-> between different tests, we have helpers that create topics/groups/... with random suffixes. See e.g. [CreateTopic()](https://github.com/deviceinsight/kafkactl/blob/main/testutil/helpers.go#L17)
+> between different tests, we have helpers that create topics/groups/... with random suffixes. See e.g. [CreateTopic()](https://github.com/deviceinsight/kafkactl/blob/main/internal/testutil/helpers.go#L20)
 
 ### Run all tests locally
 

README.adoc

@@ -28,7 +28,7 @@ You can install the pre-compiled binary or compile from source.
 
 [,bash]
 ----
-# install tap repostory once
+# install tap repository once
 brew tap deviceinsight/packages
 # install kafkactl
 brew install deviceinsight/packages/kafkactl
@@ -489,7 +489,7 @@ kafkactl consume my-topic --from-timestamp 2014-04-26
 ----
 
 The `from-timestamp` parameter supports different timestamp formats. It can either be a number representing the epoch milliseconds
-or a string with a timestamp in one of the https://github.com/deviceinsight/kafkactl/blob/main/util/util.go#L10[supported date formats].
+or a string with a timestamp in one of the https://github.com/deviceinsight/kafkactl/blob/main/internal/util/util.go#L10[supported date formats].
 
 *NOTE:* `--from-timestamp` is not designed to schedule the beginning of consumer's consumption. The offset corresponding to the timestamp is computed at the beginning of the process. So if you set it to a date in the future, the consumer will start from the latest offset.
 
@@ -502,7 +502,7 @@ kafkactl consume my-topic --from-timestamp 2017-07-19T03:30:00 --to-timestamp 20
 
 The `to-timestamp` parameter supports the same formats as `from-timestamp`.
 
-*NOTE:* `--to-timestamp` is not designed to schedule the end of consumer's consumption. The offset corresponding to the timestamp is computed at the begininng of the process. So if you set it to a date in the future, the consumer will stop at the current latest offset.
+*NOTE:* `--to-timestamp` is not designed to schedule the end of consumer's consumption. The offset corresponding to the timestamp is computed at the beginning of the process. So if you set it to a date in the future, the consumer will stop at the current latest offset.
 
 The following example prints keys in hex and values in base64: