Improve link to GitHub example

content/doc/developer/forms/form-validation.adoc

@@ -45,6 +45,14 @@ public FormValidation doCheckThreads(@QueryParameter("value") final String meani
 
 This naming convention is how Jenkins wires up your form validation method. The return type also must be FormValidation, which offers various static factory methods to create an instance. Form validation can be of 3 different kinds: `ok`, `warning` or `error`. Validation message can either be represented in plaintext or use HTML markup. Several validations of different kinds can be reported wrapping then into one using aggregate factory method.
 
+=== To set up form validation within a Jelly template
+
+To configure form validation within a Jelly template to call doCheckXxx methods defined in a particular class in Jenkins, you'll indeed utilize the checkUrl and checkDependsOn attributes. Here's a breakdown of how these attributes are used:
+
+The checkUrl Attribute specifies the URL that Jenkins will request to perform form validation. Typically, this URL points to the Jenkins server, where it handles the validation request. The value entered in the input field will be checked via AJAX against this URL, and any errors encountered will be rendered under the text field. This URL is associated with the method responsible for performing the validation (doCheckXxx method) within your Descriptor class.
+
+The checkDependsOn Attribute defines the dependency between the field being validated and the field(s) whose values are required for validation. It specifies the ID(s) of the field(s) that the validation depends on. When the dependent field(s) change, Jenkins triggers the validation of the current field. Additionally, the fields specified in checkDependsOn are sent along with the form validation request.
+
 == Getting values of other fields
 Sometimes your validation method needs values of other input fields to perform a check. You do this by defining them as additional parameters:
 

content/doc/developer/publishing/wiki-page.adoc

@@ -36,6 +36,8 @@ There are the following migration steps:
 . Modify the URL documentation page reference in the project file so that it points to GitHub (link:/doc/developer/publishing/documentation/#referencing-the-documentation-page-from-the-project-file[documentation]).
 . Commit changes, push them to your fork and create a pull request against the repository.
 
+Note:- There is a major technical obstacle in the way of content migration from the wiki. This difficulty stems from the requirement that, when the material has been properly moved, the out-of-date wiki page be removed and a redirection mechanism to the migrated version be set up. After migration, the continued existence of out-of-date wiki pages causes a number of problems, such as duplication, confusion, and unclear migration progress. This persistence not only makes the process more difficult overall, but it also makes it more difficult to identify which material has already been migrated and which is still waiting, which makes the work at hand much more difficult.
+
 === Reviewing the documentation
 
 . Review/edit the migrated file formatting