I think that many of these methods should be in a base class

This should be something like "set description text", because the whole object is a description

Moreover use const reference to pass the string

Use Const reference to pass the string

This shouldn't take a node, but rather the required node interfaces

If any implemented class inherits from the rclcpp::Node class shouldn't that class be able to fall into the rclcpp::Node parameter, or does this engage a bad practice we don't want to follow. The goal is to use the Node as a form of this, where the original issue suggests this code on something like line 48. Where this acts as the encasing class which inherits from rclcpp::Node seen on line 20 of that file.

Not everything that creates a parameter is derived from rclcpp::Node; for example rclcpp_lifecycle::LifecycleNode doesn't.

The correct approach is to pass the list of node interfaces that you are going to need

Not everything that creates a parameter is derived from rclcpp::Node; for example rclcpp_lifecycle::LifecycleNode doesn't.

Currently in this pull request I have set up two implementations for the DeclareParameter function for both of those sited nodes, after digging around the codebase I saw an implementation here. Would it be better to follow in the form of template based programming like you had made in that pull request in order to increase viability of the function?

In our case an example would be :

template<typename ParameterType, typename NodeT> 

DeclareParameter(ParameterType default_value, std::shared_ptr<NodeT> required_node){
    // Implementation
}

Why do we copy all the information? Shouldn't we just store an internal parameter description message and return it as output of a "build" method?

I interpret this as just returning the entirety of the parameter_descriptor message that we are currently using to store all the values, which makes the build method appropriate.

Before I roll out the next set of changes how would we like these three functions: SetMin, SetMax, and SetStep to act? There are multiple aspects to consider when deciding between simplicity and modularity.

Currently these three functions have no use, because the values they set are unused. In order to make them have purpose we would not only set their corresponding value, but also resize the type of range it's trying to target, if that range had not already been set. After we would then call parameter_descriptor.floating_point_range.at(0).corresponding_function. On the other hand we can opt for simplicity by removing the set functions and the values they alter all together, then in the functions that Set the Description Range we can use default values to remove possible arguments because the .msg field specifies bounds that we can have. On top of this discussion, should we also create Set functions for the int range, but with different names i.e SetMinInteger or should we aim to use overloading like SetMin(float/int min)

minor: I don't like having default values for these SetFloatingPointDescriptionRange and SetIntegerDescriptionRange APIs.
I would expect users to always set them all

should this method and SetFloatingPointDescriptionRange check the parameter type?
e.g. if the parameter is a string you shouldn't try to set these

I was expecting we were going to have the class ParameterDescription templated with ParameterType or something else to support syntactic sugar like following? So that it would be easier to create descriptor for the user application? current code almost provides the same experience with rcl_interfaces::msg::ParameterDescriptor?

above is just a pseudo cod. i might be mistaken on this, probably we want to get feedback from @wjwwood @gbalke .

While this was an option, I went with the advice in the original issue, specifically:

for the API, so that if we add more to the descriptor in the future we won't have to add/subtract/reorder arguments to a function.

The original goal was to make the floating_point_description easier to use, that's why that part is set up in the form of a general function/constructor with all the arguments declared at once.