The secretary collective will need to have its own Salary instance for handling the salary. The salary will probably be some static value, thus having a GetSalary implementation in the runtime would be the best way to achieve this. The salary is still TBD.

The secretary should also have rights to create a proposal at any rank of the Fellowship to make the process more streamlined and not dependent on fellowship members to do this, but the secretary should not get any voting rights ;)

Also maybe to make the collective more future proof, the fellowship secretary should be a special rank in the collective. Just something that we should investigate on how to do it best.

You want a specific fellowship-secretary-collective or generic secretary-collective?

I would just go with the ranked-collective. So, for sure not a specific pallet. I would assume that the ranked collective already supports all the things we need.

I should have been more concrete. I don't think that we need any kind of special/new pallet for this. All the existing pallets should be good enough for this purpose.

I assume that we only require 1 Rank(i.e SECRETARY) with the constant Candidate rank 0?

I assume that we only require 1 Rank(i.e SECRETARY) with the constant Candidate rank 0?

Yes

I think having the core pallet is needed for when more members join the Secretary Collective? @bkchr @ggwpez

I think it makes sense to openly track contributions of secretary members, as they are funded by OpenGov as well. So having the rules that are provided by the core pallet would be good IMHO.