This content comes from the third live session of the Polkadot Ambassador Alliance series, where the host Lucy invited several Technical Fellowship members to discuss the operation model of Technical Fellowship and its positioning and role in the Polkadot ecosystem! This article is quite long, so PolkaWorld will publish it in two parts; this is the latter part, mainly covering the following content:

  • How to balance full-time work and Fellowship development work?

  • Does Technical Fellowship collaborate with the JAM team?

  • Should JAM have its own token?

  • Views on the future development of Technical Fellowship

  • Will the mechanisms of Technical Fellowship change?

You can view the first part of the content here (What are the first batch of 'official employees' in the Polkadot treasury doing?)

How to balance full-time work and Fellowship development work?

Lucy: Clara, what work are you currently doing? What has been the most enjoyable or influential project in the past year?

Clara: My work in Snowbridge mainly revolves around cross-chain bridge development. Last year, our mainnet successfully launched and has been running stably for nearly a year, which excites us, and we hope it continues. Currently, we are developing Snowbridge V2, which is a major upgrade that will reduce fees, enhance flexibility, and support new use cases, and the team is very much looking forward to it. After years of development, seeing the project come to fruition is very fulfilling.

Lucy: Great! If you don't participate in Snowbridge, would you choose other projects? Or while participating in Snowbridge, can you explore other directions within the Fellowship?

Clara: Of course. I am currently developing the user interface for the Kusama cross-chain bridge, which is work outside of Snowbridge. As a Fellowship member, my responsibilities are not limited to Snowbridge; for example, last month I discovered a bug in the testing macro that caused a test that should have failed to pass — although it was a small matter, I learn new things every day.

Even without doing Snowbridge, I would be happy to engage in Polkadot technical development. While the Polkadot ecosystem only has a five-year history (just celebrated its fifth birthday yesterday!), its maturity has surpassed expectations.

Compared to the Ethereum cross-chain bridge project I participated in before, Polkadot's process management is very well-established — I have seen other public chains take a year to develop a certain feature, only to cancel it in the last few months due to process disputes, while the maturity and organization of this decentralized organization, Polkadot, is impressive.

Does Technical Fellowship collaborate with the JAM team?

Lucy: That's right, this is worth mentioning. Although Polkadot has only officially decentralized for a little over a year, it has made great strides. Oliver, you mentioned participating in the JAM project; does Technical Fellowship collaborate with the JAM team, or do you only focus on Polkadot technology?

Oliver: There are already some collaborations, and there will be more in the future. The only official collaboration is that Technical Fellowship will review the milestone submissions of the JAM Prize — when the team completes the first phase of JAM development and applies for rewards, it needs to pass Technical Fellowship's review. However, this may become a bottleneck, as there will be a large number of teams submitting results in the future, and as one of the JAM developers, I cannot participate in the review; I can only wish Clara and Donal good luck, haha.

Aside from official collaborations, many Technical Fellowship members voluntarily participate in JAM development because it is the next-generation upgrade direction for Polkadot, and understanding it in advance helps avoid future technical gaps. Parity, as the company where many Technical Fellowship members are located, is also shifting its focus toward JAM — this is an upcoming major technical iteration, naturally attracting a lot of attention.

Lucy: Awesome. Donal, have you participated in any JAM-related work? In your opinion, what is the relationship between JAM, Polkadot, and Technical Fellowship? This is a question I often get asked, and Oliver just mentioned that JAM is the next-generation upgrade direction for Polkadot. How does Technical Fellowship view it? Do you think this is an extension of the same system?

Donal: Well, I actually haven’t specifically participated in JAM-related work, but I've been following it because I think it's a very interesting development direction for Polkadot. I believe JAM is the next generation iteration of Polkadot, but in a completely different way. If we trace back to the basic concept, it’s somewhat like the 'next-generation cloud platform' of the Polkadot network. The Polkadot Hub could completely maintain its existing architecture in the future, just running on top of JAM, so I see it as a continuation, but with significant changes — compared to the recent upgrade from Polkadot 1.0 (before elastic scaling) to Polkadot 2.0 (after elastic scaling), the differences between Polkadot 2.0 and the Polkadot Hub running JAM are like heaven and earth.

In the coming years, how we promote this transition, or how developers migrate traditional Polkadot technical experience to JAM and future Polkadot services, is something to look forward to.

I guess if you ask every Technical Fellowship member, 'What do you think about the relationship between JAM and Technical Fellowship?' you might get 40 different answers, haha. But the core is: the skill set of Technical Fellowship is sufficient to support JAM development, and after completing a certain milestone (I remember it was milestone three?), JAM developers can automatically obtain Technical Fellowship level three qualifications. Oliver, did I get it wrong? Is it milestone three?

Oliver: I remember that completing milestone one can earn a level three qualification voucher and a level two qualification voucher, but they must be used by team members and cannot be resold. I previously asked if they could be sold, but the answer was no; they must be used internally within the team.

Donal: Yes, this indicates that there is already a direct mechanism. Even if you have never participated in 'classic Polkadot' development, as long as you participate in the JAM project, you can directly join the Technical Fellowship. I think the transition will be very smooth, but we just need to clarify the specific pathway, and not just for Technical Fellowship, the entire Polkadot network's transition to JAM is also very worth paying attention to.

Should JAM have its own token?

Lucy: So how do you all feel about the topic of whether JAM should have its own token? Of course, you can choose not to answer, haha.

Donal: I think both sides have a point, haha.

Lucy: This topic has been particularly hot on Twitter recently, so I just wanted to ask.

Donal: Personally, I don't have a particularly strong stance, other than being a DOT holder, haha. Whether or not a new token is issued, I believe it will ultimately create value for DOT. If a new token is issued, it must be because it excels in some aspects compared to directly continuing to use DOT, and it is very likely to be airdropped to DOT holders in proportion, thus maintaining the value of DOT through the empowerment of the new token. Conversely, continuing to use DOT as a mature token, relying on its existing holders and uses, and serving directly as a transaction fee token is also feasible. Both options are possible; I don't have a strong preference, as long as the decision is reasonable, it won't be catastrophic.

Lucy: Yes, I see it that way too. I actually don't understand why this topic would cause such a big controversy; my view is almost the same as yours.

Oliver: I think the core of this controversy is still about the brand. In my view, there are currently three possible futures:

  • The JAM brand 'swallows' the Polkadot brand;

  • The Polkadot brand 'swallows' the JAM;

  • The two brands compete side by side.

The third option is actually the hardest to clarify, as it is difficult to explain to the outside world how two highly similar yet partially overlapping brands can coexist. This type of communication will be very tricky in marketing, so I personally prefer either the first or second option, directly retaining one brand and removing the other for clarity.

But the reality is: currently, we do not have a clear direction. JAM has its own official website, brand, and visual system, while DOT, as an existing brand, is also very mature. They are currently somewhat on a 'colliding' trajectory, which is the root of the controversy — if we do not eliminate one of them, it is hard to find a simple solution. Moreover, this topic was not originally planned for public discussion; the result was that at last week's Open Dev Call, a developer suddenly mentioned it, and now the entire community is paying attention, while we were not prepared with a stance or official statement at the time, leading to a situation where everyone is 'blindly feeling their way across the river'. However, this matter must be resolved sooner or later.

Lucy: Next week, everyone will have other things to focus on, so don't worry, haha.

Donal: Haha, right, it also indicates that the operation of our Technical Fellowship is quite transparent — we members only found out about this topic being raised after Gavin publicly mentioned it.

Views on the future development of Technical Fellowship

Lucy: This state has both advantages and disadvantages! With the remaining time, I want to talk about the future of Technical Fellowship. You know I joined Parity in March 2022, and in June, Gavin proposed the initial version of the technical declaration. At that time, I knew nothing about Polkadot and only remembered it was all about 'stones' (laughs). Because for those unfamiliar, Technical Fellowship is divided into 10 levels, each corresponding to a type of stone, with greater density as you go up, and the highest level, Rank 10, is black diamond. Later, I participated in writing the Polkadot technical declaration aimed at the community, so this content became very meaningful to me. However, looking back, the entire Fellowship is still quite new, as it is said to take 19 years to reach Rank 10, haha. So I want to ask you, what are your expectations for the Fellowship in the coming years? What do you and your team define as 'success'?

Oliver: That's a good question. From an organizational perspective, I think we should allow more members from teams outside of Parity, and even be legally and geographically more decentralized. Right now, most of us are concentrated in Europe because many people live here. From a development perspective, increasing the number of Technical Fellowship members is also a goal, so we can handle proposals and reviews more competently.

I heard that there will be a Polkadot palace in Lisbon in the future, which could serve as an offline gathering point for future Technical Fellowship members. I think that's good too, as it represents development at the organizational level. From a personal perspective, many people may still hope to be promoted; moving up in rank itself is a motivation, and that applies to me as well.

Lucy: Clara, what about you?

Clara: I hope that more people who are genuinely involved in the Polkadot ecosystem will join Technical Fellowship, such as developers from various parachains.

This can achieve better decentralization on one hand and reduce dependence on Parity on the other — after all, I understand that one of the original intentions of establishing Technical Fellowship was to avoid such centralized dependence. I also believe that those who actually use Polkadot should have more say: some designs that seem reasonable from an academic perspective may need to be adjusted in practical use, so having more user perspectives is very important. Personally, I don't mind if I remain Rank 1 forever; the key is to participate in this ecosystem, contribute value, and watch it grow, which is already cool for me.

Lucy: Awesome, thank you! What about you, Donal? Do you have any big plans for the future?

Donal: I think it will be interesting to see how Technical Fellowship 'matures' from an organizational perspective in the future. The current structure is quite crowded at the 'base of the pyramid' — there are many low-level members. In contrast, Ambassador Fellowship does not have this problem because they have not yet started the 'seed stage' and already have a batch of more mature members ready to join. Technical Fellowship's selection criteria at the seed stage were not very clear, so we may have started screening from a relatively 'basic' level. Now, new members who join, such as someone from another blockchain ecosystem who is capable enough to reach Rank 4, still have to start from Rank 1; this situation is quite common. One manifestation of 'maturation' is that Technical Fellowship should ultimately be able to identify and position the true level of different members, rather than letting people quickly 'level up'.

For example, many people can be promoted every year, indicating that the entire organization is still in its early stages — everyone has not fully figured out what abilities each rank should have. Sometimes, lower-ranked individuals may actually be very capable, while higher-ranked individuals may not reach the corresponding level. Therefore, I think it will be crucial in the coming years to see how Technical Fellowship establishes stable assessment standards and allows high-ranked members to have a more powerful voice in proposals or votes.

Of course, I also agree with the points Oliver and Clara mentioned, such as being more decentralized and bringing in more new members, etc. Personally, I am also very much looking forward to the changes brought by the OG Rust bounty, hoping to attract some strong development teams from outside the ecosystem to join Polkadot, and then stay and become Technical Fellowship members, injecting fresh blood.

Will the mechanisms of Technical Fellowship change?

Lucy: Awesome, the last question — you mentioned a lot of things you hope will happen, but is there any feedback mechanism in reality? Three months ago, I sent out a questionnaire to collect feedback, but people generally don't like to read and write unless it's coding, haha. So I want to know if you have any feedback channels, or how these suggestions are eventually implemented?

Oliver: The current 'feedback mechanism' is basically just @ people in chat groups and directly mentioning your dissatisfaction in internal channels; it's a relatively 'direct line' approach. We don't have anonymous feedback forms or channels for quiet submissions yet, and I personally feel that we haven't reached the point where a systematic feedback process is necessary.

However, some things that have happened recently, such as someone being 'mistakenly demoted', have indeed sparked internal discussions, and everyone expresses their opinions to each other, reaching a consensus before executing. So now, the main approach is still to rely on communication and logical persuasion to drive changes. Of course, even if a feedback collection channel is established in the future, it doesn't mean everyone will understand or value this feedback, so sometimes you still need to voice your opinions clearly to drive change.

Lucy: So if everyone really has ideas, like 'we should modify a certain rule', can it be decided by vote? Can the technical declaration be changed?

Oliver: Yes, the declaration can be modified. However, in theory, the changes still need to be re-approved through OpenGov, so currently, we tend to 'keep it as is' and have not made many proactive modifications.

Donal: During last year's Web3 Summit, Alice and Bob gave a great presentation; I can't remember the exact title, but the core point is: if there is a clear declaration, there will be a higher threshold for modifications, avoiding frequent policy changes. This way, you will be more cautious during the initial setting, and once established, it will only be changed if a serious problem arises and there is sufficient support.

Lucy: Yes, our ambassador program declaration is handled the same way. If it's just a minor change, we decide internally; if it's a major change, it needs to go through the OpenGov process. I think you're right, this mechanism is very important; otherwise, the document will become unstable and lack direction.

Donal: I'm just curious, who defines what constitutes a 'minor change'?

Lucy: Uh, this is judged directly by the standards from Technical Fellowship. For example, if you want to add a line to the code of conduct, that counts as a minor change; but if it involves fundamental content like voting weight or level expectations, that counts as a major change. We initially hoped this system would be more flexible, scalable, and adaptable to future changes, so we also maintained a certain level of flexibility in the definition of 'levels'. Rather than 'modifying' certain content, we prefer to 'refine the details', after all, we were allocating 164 people into the first four levels, and we haven't started allocating the last two levels yet. We are also going through a similar phase as you, and although we are generally quite satisfied with the initial level assessments, there are indeed individual cases that may need adjustment, which will be addressed in the second phase.

Currently, there is no content to modify in the declaration itself, but in the future, if there are any, such as feeling that Rank 4 members must regularly spend time participating in the internal work of Ambassador Fellowship, that would be a more fundamental change that requires a vote.

Oliver: We haven't even corrected typos here, haha. But we do have a 'natural advantage' — this declaration was originally written by Gavin, so everyone respects it a bit more. It might sound a bit silly, but it really is a factor.

Lucy: I completely understand. When I was drafting the community declaration, I specifically invited the community to participate in the writing, and it went through five revisions before submitting to Gavin. It should be noted that the only part I directly modified was the mathematical calculation of 'voting weight' on GitHub. Originally, someone calculated the voting weight of Rank 6 as 243, while I, as Rank 1, was far from being equal, haha. Later, Gavin personally pointed out that this algorithm was incorrect, and I made the change. If anyone is interested, they can check it out on GitHub. Alright, our time is up, thank you all very much! Before we end, I have a reserved question for each guest: 'If you imagine Polkadot as a person, what word would you use to describe him/her?' Clara, you go first.

Clara: Sophisticated.

Lucy: Wow, this is the first time someone has used this term, very good, thank you! What about Donal?

Donal: Although not very fitting, I have always thought of it as 'correct' — no matter good or bad, it always insists on the right direction.

Lucy: That's interesting. I've conducted four sessions, and I've asked this question each time; I've now asked more than twenty people, and surprisingly, there haven't been any repeated answers. That's so cool! Oliver?

Oliver: Then I will say 'Vibrant'.

Lucy: Another new term! Awesome, thank you all! I've really learned a lot, and I hope the audience can learn something too. I hope we can have such discussions quarterly in the future to delve deeper into what you're actually doing, allowing everyone to better understand the growth of Technical Fellowship and the ambassador program. Thank you very much, goodbye!

Original video: https://www.youtube.com/watch?v=5AyHuAUgdfM