I will use the word "contributor" to refer to programmers who contribute changes to code, and to everyone else who makes useful changes. It is a better term than "resource," because it focuses attention on what we want (contributions), rather than implying that there are objects to be controlled (resources).
Software is an ecosystem, and some contributors are likely to come from outside of your existing team and management structure.
In the old days, there was just one version of a piece of software and several programmers could edit it, like a bunch of painters working on different areas of a fresco.
With the Internet and modern version control systems, we have a lot more choices in the workflows we use to collect and handle changes to code. We might test each change personally before adding it to the shared version. This is a "maintainer" workflow. Before merging changes to the shared version, we might ask some team members to vote on it. This is a team review workflow. We might have a machine test the changes and warn the contributor if there is a problem. Choosing the right code contribution workflow for your environment will help you scale up software development to bigger teams and faster releases.