"slave" terminology was deprecated in Jenkins 2.0 and was hence replaced with "agent" Issue - JENKINS-42816.

[nagu165]

See JENKINS-42816.
As a beginner i request you to kindly review my work and provide suggestions on how to move forward.

Testing done

Result was given as :

When i went to the documentation page to get the details of the error, It was said to be an issue with a plugin rather than of the jenkins core.
If this is wrong or it requires some further intervention please let me know.

Proposed changelog entries

• human-readable text

Proposed upgrade guidelines

N/A

Submitter checklist

Preview Give feedback

1. The Jira issue, if it exists, is well-described.
2. The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples). Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
3. There is automated testing or an explanation as to why this change has no tests.
4. New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
5. New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
6. New or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
7. For dependency updates, there are links to external changelogs and, if possible, full differentials.
8. For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@mention

Before the changes are marked as ready-for-merge:

Maintainer checklist

Preview Give feedback

1. There are at least two (2) approvals for the pull request and no outstanding requests for change.
2. Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
3. Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
4. Proper changelog labels are set so that the changelog can be generated automatically.
5. If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
6. If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[welcome]

Yay, your first pull request towards Jenkins core was created successfully! Thank you so much!

A contributor will provide feedback soon. Meanwhile, you can join the chats and community forums to connect with other Jenkins users, developers, and maintainers.

[MarkEWaite]

I've removed the newbie-friendly label from that epic because there is a tendency for new contributors to not read the entire description of the issue.

This pull request proposes breaking changes with no attempt at compatibility. That's contrary to Jenkins project governance document where we have a section "Compatibility Matters" that describes how important compatibility is to Jenkins users.

if you'd like to help make progress on the deprecation of the "slave" term, you're encouraged to do so, but it needs to be done in a way that preserves compatibility. Smaller pull requests that change a specific detail are more likely to be considered and more likely to make progress than a pull request that changes over 800 files, does not compile, and does not pass automated tests.

[MarkEWaite]

I'm closing this pull request. You're welcome to submit additional pull requests, but a pull request of this size and this impact is unlikely to be accepted from a new contributor.

[nagu165]

Understood sir, Thank you for the response.
sorry for this pr, I'll choose the issues to work on very carefully from now on.
If i may add something, I think it would be better to mention "Scope" before the "Newcomer-friendly issues" in the issues as newcomers like myself might not get to the actual "scope" part after going through the examples in the friendly section.

Thank you for your patience.

[MarkEWaite]

I think it would be better to mention "Scope" before the "Newcomer-friendly issues" in the issues as newcomers like myself might not get to the actual "scope" part after going through the examples in the friendly section.

Thanks for the comment. I think that you're referring to the "scope" heading in the JENKINS_42816 epic description. That text is specific to that epic, not a general pattern that applies to all issues.

I think that it is reasonable to expect new contributors to read the entire description of an issue before they contribute to the issue. Most open source communication is asynchronous. It depends on each of us to read what is written and to use what we learn from the written information. There are many times when I need to read the issue description multiple times to assure that I understand it. I don't think that moving the "scope" heading and its text to the top would reduce the need to read the entire description

[nagu165]

Yes sir, Understood.
I'll be very careful with an issue from now on.

[nagu165]

I think that it is reasonable to expect new contributors to read the entire description of an issue before they contribute to the issue.

yes sir, it is.
I sincerely apologize for my mistake and thank you for the feedback.

[MarkEWaite]

No problem at all. Thanks for contributing to open source software and thanks especially for contributing to Jenkins. We're learning together and that is good for all of us.