St George for Delegate
- Thread starter St George
- Start date
- Pronouns
- He/Him, They/Them
My apologies for this - but I will not be able to make this.
I will try to host a Town Hall on Tuesday or Wednesday.
I don't think taking a closer look at the region's tech is a bad idea per se, and you identified issues with access and a cards program we did not get off the ground, but I wanted to say a few words on the subject because I think people have started to get the wrong idea. And I am saying it here because this is one area where you and Dreadton diverge quite a bit - he does not think this is actually a problem we need to tackle, and as I lay out below, in a lot of ways he is not wrong (that is to say, the solution to the problems we have had are simpler and don't require looking at the code or the people providing it at all).
First and foremost, as I continue to look into this issue and actually hear what went wrong the common thread is user error. What we need perhaps even more than a review of our tech, is better tech education. People need to follow directions and use the tools as intended, or they break. Many of the frequent tech snafus this term were a result of things like this. I just posted in the Speaker campaign thread because this notion of broken scripts crept into the one place where it was most obviously user error that created the problem. Admin can fix things that go wrong, no matter the cause, but if the cause is us, we need to own that and also keep that in mind so future errors of that kind don't persist.
Secondly, admin needs to be made aware of these problems and given time to fix them, because sometimes there's a delay in their ability to respond or it just takes a few days to fix. Speaking as the person who reached out to r3n about sheet access for some players, I can tell you that once he was aware, he fixed it, and that was only necessary because the person who had the ability to do that (McM) was unable to do it. In this case, while we normally would rely on one specific person, we actually had a second who could assist. A similar thing happened with handling the cabinet archive on Discord. We do have more than one person we can call on when the primary person is unavailable, but you have to know who the people are, and you have to actually reach out to them.
The biggest issue with our script this term, outside of the initial access and reassigning at the start, was an issue on NS's end with the happenings. That wrecked all our scripts and causes TGs to go out hat shouldn't. I can attest that this issue felt like it went on for a while, but in truth it was only a few days. Perception has become reality and all of these little things plus that big thing have added up to this idea that our tech is a mess. It is not. What we have are the same problems we have had in other areas: poor communication, spotty availability, and general incomplete knowledge. If you are going to use these tools, make sure you know how to use them. If you are going to make changes or try something new, make sure you make other people aware. It's easy for someone to make one edit and not realize the consequences, and then no one knows why the script suddenly stopped working.
As it relates to relying on one person: yes, this can sometimes be risky and bite us. But given how complicated this stuff can be, that is almost unavoidable. There are some areas where we can easily rely on multiple people (people to grant access to these things, as previously mentioned, or people who have experience using them and can step in as needed to execute commands), but when it comes to actually fixing code, few can do that. Fewer still, when the code is designed by an individual who knows how to read it and essentially has their own language for it that other code-experienced people may not be able to understand. And we are not the only region in this situation - ask around and you'll see that one or two people are relied upon for the code our friends and allies use. I do not know how we can bring in another person without essentially being forced to replace our existing scripts with the new person's, and creating the same scenario we have now. I would like to train one other person to be able to work the code at least, but that still requires a lot of time for r3n to train this person, not to mention no small amount of trust to be placed in that person. And that instruction is essential, because a personalized code that makes sense to the user won't make sense to everyone who can read code. Not to mention the people who don't get code who may be asked to step up should we have an emergency...I shudder to think of what that looks like.
And then you get into the open source stuff. But I'm also not sure what open source has to do with our situation - that's something contemplating a wider distribution of the code isn't it? Not so much a question of having extra hands to use our tech, especially considering the "how to use it" problem, which implies a greater number of people using it beyond TNP. That's an entirely different set of questions and discussions to have, and kind of goes outside the scope of the problem you identified, MadJack, which is relying on only one person for fixing our code. I'm in danger of talking beyond my own knowledge here, but I think the question of open source isn't really directly related to the problem you want to solve.
I am fairly confident that you will agree with these points wholeheartedly, MadJack, and that any tech review you do would come to the same conclusions I have outlined. But I wanted to lay this stuff out since it has become a key part of your platform, and I want to make sure you're taking these things into consideration.
First and foremost, as I continue to look into this issue and actually hear what went wrong the common thread is user error. What we need perhaps even more than a review of our tech, is better tech education. People need to follow directions and use the tools as intended, or they break. Many of the frequent tech snafus this term were a result of things like this. I just posted in the Speaker campaign thread because this notion of broken scripts crept into the one place where it was most obviously user error that created the problem. Admin can fix things that go wrong, no matter the cause, but if the cause is us, we need to own that and also keep that in mind so future errors of that kind don't persist.
Secondly, admin needs to be made aware of these problems and given time to fix them, because sometimes there's a delay in their ability to respond or it just takes a few days to fix. Speaking as the person who reached out to r3n about sheet access for some players, I can tell you that once he was aware, he fixed it, and that was only necessary because the person who had the ability to do that (McM) was unable to do it. In this case, while we normally would rely on one specific person, we actually had a second who could assist. A similar thing happened with handling the cabinet archive on Discord. We do have more than one person we can call on when the primary person is unavailable, but you have to know who the people are, and you have to actually reach out to them.
The biggest issue with our script this term, outside of the initial access and reassigning at the start, was an issue on NS's end with the happenings. That wrecked all our scripts and causes TGs to go out hat shouldn't. I can attest that this issue felt like it went on for a while, but in truth it was only a few days. Perception has become reality and all of these little things plus that big thing have added up to this idea that our tech is a mess. It is not. What we have are the same problems we have had in other areas: poor communication, spotty availability, and general incomplete knowledge. If you are going to use these tools, make sure you know how to use them. If you are going to make changes or try something new, make sure you make other people aware. It's easy for someone to make one edit and not realize the consequences, and then no one knows why the script suddenly stopped working.
As it relates to relying on one person: yes, this can sometimes be risky and bite us. But given how complicated this stuff can be, that is almost unavoidable. There are some areas where we can easily rely on multiple people (people to grant access to these things, as previously mentioned, or people who have experience using them and can step in as needed to execute commands), but when it comes to actually fixing code, few can do that. Fewer still, when the code is designed by an individual who knows how to read it and essentially has their own language for it that other code-experienced people may not be able to understand. And we are not the only region in this situation - ask around and you'll see that one or two people are relied upon for the code our friends and allies use. I do not know how we can bring in another person without essentially being forced to replace our existing scripts with the new person's, and creating the same scenario we have now. I would like to train one other person to be able to work the code at least, but that still requires a lot of time for r3n to train this person, not to mention no small amount of trust to be placed in that person. And that instruction is essential, because a personalized code that makes sense to the user won't make sense to everyone who can read code. Not to mention the people who don't get code who may be asked to step up should we have an emergency...I shudder to think of what that looks like.
And then you get into the open source stuff. But I'm also not sure what open source has to do with our situation - that's something contemplating a wider distribution of the code isn't it? Not so much a question of having extra hands to use our tech, especially considering the "how to use it" problem, which implies a greater number of people using it beyond TNP. That's an entirely different set of questions and discussions to have, and kind of goes outside the scope of the problem you identified, MadJack, which is relying on only one person for fixing our code. I'm in danger of talking beyond my own knowledge here, but I think the question of open source isn't really directly related to the problem you want to solve.
I am fairly confident that you will agree with these points wholeheartedly, MadJack, and that any tech review you do would come to the same conclusions I have outlined. But I wanted to lay this stuff out since it has become a key part of your platform, and I want to make sure you're taking these things into consideration.
- Pronouns
- It
- TNP Nation
- Simone_Republic
What are your plans to increase membership of TNP given that we are now fifth in headcount? (Or as I'd put it, how to Make TNP Great Again?) I am most concerned about WA so expanding the roster is my personal priority.
- Pronouns
- He/Him, They/Them
As far as I'm aware, we're already in talks about our N-Day alliance - whether that means we end up taking a more aggressive approach this year would be a discussion to be held within that alliance.
There's not really much we can do unless we start recruiting directly from other feeders - or, when they're instituted, frontiers. What I will say though is that the only reason TNP is fifth in headcount is due to card puppets - some users have revived hundreds and even thousands of card farming puppets and left them in the sinkers. Chicken Overlords, similarly, is only top because it's a puppet farm. There's not really a community there (or, at least, one as large or sustainable as TNP).
We can take a look at what we're doing with regards to retention and outreach and mentoring but from what I've observed over the last term, we're actually pretty good at it.
I'll respond to Ghost when I have a bit more time this afternoon.
- Pronouns
- He/Him, They/Them
I agree with almost all of this, but with regards to access, it's the end of the term and there's still things we don't have access to, still things we've asked for access to and just don't have. The Retaliatory Recruitment and Civil Defense Siren sheets spring immediately to mind - the only reason we've been able to update them is because Tlomz had access. That to me, isn't really acceptable. It's ok in a pinch, but the right people should be getting access, and it should happen early in the term. It was brought up that we could reach out to r3n about it but we got told that it was unlikely to have an effect. If that wasn't the case, then that's very unfortunate, also.
You are correct, though, about tech education. It took me a while to get to grips with the tools the Speaker's office has to begin with, and we had an active COE around at the time to address the one script error we had at the time. I think our review would definitely have to address that, and as part of that, making sure ministers, staffers and other people with access to the tools know how to use them, how to avoid user error and what to do when an error occurs, all needs to be addressed. I think a tech handbook, akin to what Praetor did with his diplomatic guide, might be a good idea here.
With regards to open source, I think that if there's open source alternatives to our tools - there isn't, as far as I'm aware - we should consider adopting them, at least as backups, as that would allow anyone with a passing knowledge of how to set up such things to step in if required. But I think that's only something to pursue in specific circumstances - like if our tech is down, our coders are unreachable and we don't have the code for our existing stuff. I think looking too much into open source stuff would become a distraction, but I'm not entirely sure we should not look at all.
It is however, as you say, largely outside the scope of our problems - which is overreliance on a few people to run them, and the very spotty access we've had over the last time.
Regarding spreadsheet access, I want to clarify that I have not had any role in managing spreadsheet access for more than three years now (definitely since 2018, but I think it's been since 2016 or maybe even 2015). Spreadsheet access has been managed originally by Asta, and for at least two years now by mcm.
In late 2020, I actually had the foresight to create a Google account that was shared between mcm and myself, and asked mcm to transfer ownership of all spreadsheets to that account. The plan was that mcm would continue to manage access, whereas I would use the account for standard maintenance (sometimes, as I debug scripts, I need owner access to test various settings). Fast forward to May 2021, I was absolutely unaware that there were access issues, given that I did not know mcm was away and nobody whatsoever had mentioned these access issue to me (despite the fact that many people pinged about other bugs that needed fixing). The first person to bring up access issues to me was Ghost, who did so via DM on June 5th. Once he let me know, I opened up this shared Google account to all admins, and the access issues were resolved.*
I agree that it is unfortunate that, for a period of one month, the government did not have access to spreadsheets. But:
1) It seems to me that this is more of an issue of communication than an actual infrastructure issue. (Almost?) all admins, and a lot of non-admin TNPers, frequently DM me on discord, and yet none thought to bring this up with me in case I had a solution---which I did.
2) It is a one-time incident in the span of 7 years we have been using our collection of spreadsheets.
3) It is also a one-time incident that was caused by a unique set of circumstances, namely mcm becoming completely unavailable.
4) We have already rectified this issue* through the shared admin account.
So yes, it was an unfortunate incident, that has largely been alleviated and is unlikely to occur again.
Outside of the access issue, I have not seen some increased frequency in problems running our existing scripts, compared to what we had before. The occasional hiccup, wrong list, accidental telegram, and so on, have been happening since the very beginning of our use of scripts. And both Elu and I continue to fix the issues that get reported to us reasonably fast---on my end, I generally cannot do so on weekdays, but I fix any issues in the following weekend, which is a max turnaround time of a week.
I do agree with Ghost that having better guides for using the various spreadsheets is an important that the various government officials using those spreadsheets, in coordination with admin, should prioritize. In the past, I have put together guides for a few of the spreadsheets, e.g., the WADP, IFV, MoHA happenings, etc. I was under the impression that one already existed for the Citizenship spreadsheet, but apparently that was wrong. I will note, though, that in some cases, people either seemingly do not bother to read existing guides and end up making mistakes (the IFV comes to mind), or just go out of their way to make drastic changes to spreadsheets that any reasonable person should expect to break things (a recent incident with the telegramming exceptions spreadsheet comes to mind).
*The retaliatory recruitment spreadsheet that StG mentioned is the one exception. It looks like mcm neglected to transfer access of this spreadsheet to the shared account when we were doing the en masse transition. I didn't know about this until Siwale brought this up in a DM a few minutes ago. I'll try to fix this later this afternoon. That said, it would be a stretch to describe having to, from time to time, ask Tlomz or some admin to update this list as such an onerous task, given that this is far from a daily task.
In late 2020, I actually had the foresight to create a Google account that was shared between mcm and myself, and asked mcm to transfer ownership of all spreadsheets to that account. The plan was that mcm would continue to manage access, whereas I would use the account for standard maintenance (sometimes, as I debug scripts, I need owner access to test various settings). Fast forward to May 2021, I was absolutely unaware that there were access issues, given that I did not know mcm was away and nobody whatsoever had mentioned these access issue to me (despite the fact that many people pinged about other bugs that needed fixing). The first person to bring up access issues to me was Ghost, who did so via DM on June 5th. Once he let me know, I opened up this shared Google account to all admins, and the access issues were resolved.*
I agree that it is unfortunate that, for a period of one month, the government did not have access to spreadsheets. But:
1) It seems to me that this is more of an issue of communication than an actual infrastructure issue. (Almost?) all admins, and a lot of non-admin TNPers, frequently DM me on discord, and yet none thought to bring this up with me in case I had a solution---which I did.
2) It is a one-time incident in the span of 7 years we have been using our collection of spreadsheets.
3) It is also a one-time incident that was caused by a unique set of circumstances, namely mcm becoming completely unavailable.
4) We have already rectified this issue* through the shared admin account.
So yes, it was an unfortunate incident, that has largely been alleviated and is unlikely to occur again.
Outside of the access issue, I have not seen some increased frequency in problems running our existing scripts, compared to what we had before. The occasional hiccup, wrong list, accidental telegram, and so on, have been happening since the very beginning of our use of scripts. And both Elu and I continue to fix the issues that get reported to us reasonably fast---on my end, I generally cannot do so on weekdays, but I fix any issues in the following weekend, which is a max turnaround time of a week.
I do agree with Ghost that having better guides for using the various spreadsheets is an important that the various government officials using those spreadsheets, in coordination with admin, should prioritize. In the past, I have put together guides for a few of the spreadsheets, e.g., the WADP, IFV, MoHA happenings, etc. I was under the impression that one already existed for the Citizenship spreadsheet, but apparently that was wrong. I will note, though, that in some cases, people either seemingly do not bother to read existing guides and end up making mistakes (the IFV comes to mind), or just go out of their way to make drastic changes to spreadsheets that any reasonable person should expect to break things (a recent incident with the telegramming exceptions spreadsheet comes to mind).
*The retaliatory recruitment spreadsheet that StG mentioned is the one exception. It looks like mcm neglected to transfer access of this spreadsheet to the shared account when we were doing the en masse transition. I didn't know about this until Siwale brought this up in a DM a few minutes ago. I'll try to fix this later this afternoon. That said, it would be a stretch to describe having to, from time to time, ask Tlomz or some admin to update this list as such an onerous task, given that this is far from a daily task.
Last edited:
To clarify, I have been available to the executive to handle spreadsheet masking issues as they come up since r3n expanded access to the spreadsheet owner account on June 5th. The Delegate, former Vice Delegate, and various cabinet officials have reached out for masking requests. The issue regarding McM's ownership of the Executive Staff Master Sheet was brought to me via this process. However, nobody informed me of an issue with the retaliatory recruitment spreadsheet. MJ's mention in this thread is the first time I learned of it and thus is why r3n is just hearing about this now as well. As for the Civil Defense Siren sheet, we do own that and the current Delegate has editor access. If any additional access is needed at the delegate's discretion, please reach out via either a request in the admin request thread or a direct DM to me. We can't help if we don't know what the issue is.
- Pronouns
- He/Him, They/Them
It very much does seem like a communications, now that you've both posted. It... illuminates some things for me and I apologise if any of the things I've said about our tech felt like unjustified criticism.
I'm now very, very confused - in cabinet we were led to believe that r3n was unavailable and getting a message to him was not particularly likely to be productive in addressing issues. I brought up both the CDS and Retaliatory Recruitment sheets more than once and was told that only McM or - less likely due to the difficulty it was suggested that contacting r3n took - could grant access to that, and that lack of access, coupled with the lack of access or existing tech infrastructure elsewhere (Cards gifting, mainly), is what led to such a heavy focus on the tech infrastructure in my platform.
I still think a tech review would be productive, but the scope of such a review may be changing from what I originally had planned.
Regarding card gifting, I should clarify that this is tech infrastructure that does not exist. Before my retirement, most of the card gifting was done by me semi-manually---by that I mean scripts that allowed me to accelerate manual tasks, like clicking a button to gift a card, etc.
McM did reach out to me in May about the possibility of creating a card gifting service, so that other users can access the decks of TNL and the "card farmer" nations and gift cards in an automated way. I promised to work on that, but I have not yet delivered. I apologize for this, though I should point out that this is not for lack of trying: I have actually already coded up most of the service, but for a while I was being held up by the fact that I needed some information from the NS admins regarding API use. I have now gotten the information I needed, but end-of-summer RL deadlines and the start of the academic semester have prevented me from completing the project.
I will try to wrap up the card gifting service soon, hopefully this weekend. But, I wanted to clarify again that, in the case of cards, we are talking about the creation of new infrastructure, rather than bugs/lack of access to existing one.
This makes me wonder whether having a reporting mechanism separate from the admin requests for tech issues (e.g., some dedicated page where people post questions or problems they run into) would help make communication and resolution of bugs easier. It will inevitably result in some duplication with admin requests, and some spam. But, so long as people use it responsibly, it could help avoid some of the confusion that StG points out.
----------
I don't have any strong preference for or against a tech review. Having one could help identify vulnerabilities with our existing tech (e.g., places where we lack fallback automated or manual solutions), and it can also help come up with a plan for other related issues (e.g., the need for use manuals and training that Ghost brought up, the communication barriers and possibility for a new page that I mentioned above). I just hope that prior experiences and difficulties with our tech infrastructure will be correctly contextualized in such a review.
McM did reach out to me in May about the possibility of creating a card gifting service, so that other users can access the decks of TNL and the "card farmer" nations and gift cards in an automated way. I promised to work on that, but I have not yet delivered. I apologize for this, though I should point out that this is not for lack of trying: I have actually already coded up most of the service, but for a while I was being held up by the fact that I needed some information from the NS admins regarding API use. I have now gotten the information I needed, but end-of-summer RL deadlines and the start of the academic semester have prevented me from completing the project.
I will try to wrap up the card gifting service soon, hopefully this weekend. But, I wanted to clarify again that, in the case of cards, we are talking about the creation of new infrastructure, rather than bugs/lack of access to existing one.
I have noticed, in general, that there seem to be communication barriers between the admin team and the larger community regarding tech issues. For example, another campaign thread made mention of some DNS issues trying to get the citizenship registry to work---DNS issues that have never been reported to either me or any other member of the admin team, despite sounding quite severe from their description.
This makes me wonder whether having a reporting mechanism separate from the admin requests for tech issues (e.g., some dedicated page where people post questions or problems they run into) would help make communication and resolution of bugs easier. It will inevitably result in some duplication with admin requests, and some spam. But, so long as people use it responsibly, it could help avoid some of the confusion that StG points out.
----------
I don't have any strong preference for or against a tech review. Having one could help identify vulnerabilities with our existing tech (e.g., places where we lack fallback automated or manual solutions), and it can also help come up with a plan for other related issues (e.g., the need for use manuals and training that Ghost brought up, the communication barriers and possibility for a new page that I mentioned above). I just hope that prior experiences and difficulties with our tech infrastructure will be correctly contextualized in such a review.
Last edited: