gonna purposefully fill it out wrong to spoil the results

>>10558
That's why questionaites have text fields rather than only checkboxes

>>10559
you underestimate what lengths I will go to to be obnoxious

A third party website is what you'll use right?

>>10561
no

a program to recieve feedback forms would be useful so no, not going to use google's product for this, for example

Seems reasonable. I can't think of anything

>>10563
>>10562
>>10561
everything I do at this point is basically preparatory work for a major work. That means writting the feedback reciever as a way to build up knowledge on various good practices with golang.. so even though actually recieving it could be done with a third party service there are multiple reasons why it's not in my interest to do this.

>>10557
>Idea is the poll will be anonymous so you don't have to threat about me not liking anything
...As opposed to what? It's not like we have accounts or established identities on here regardless, and I presume you can see our IPs even if the survey is supposedly 'anonymous'.

Nitpicking aside, I enjoy polls and surveys, so I'm sure I'll fill it out if you go ahead with it. For general site feedback though, as opposed to demographics and such, wouldn't a permanent feedback form make more sense than a one-off survey?

>>10566
I'm not going to be reading through NGINX logs to figure out if the person is real or not, but on the polls in /poll/ I have ways to tell if they're proxy IPs with no history.

Basically, the responses could be false and what will decide what I see as valuable or not is if it makes sense. You might think "oh no people are going to spam bogus feedback", but the thing is that all feedback has value and can be worked with.

There are many uses to having a server setup to recieve feedback forms. For example what you describe. Though this survey wouldn't be one-off, it will probably stay up forever and we'll have feedback.kissu.moe or kissu.moe/feedback

id answer.

>>10567
Seems like a good idea, I'm just worried what it means for the feedback thread.

>>10570
that thread is strongly software oriented, but even then the reason to use a form vs thread don't detract from one another

>>10557
They do this over at frenschan and it clogs up most of the board and they put it on the welcome page, having a dedicated url would solve that but how would you hed people over to the questionnaire?

>>10557
>proficiency with imageboards
i'm an imageboards and online communities otaku

>>10593
I wish I could have even a tenth of the social skills that surely must require.

I'm setting my time to start building these sorts of mini projects(a feedback reciever) as of Sept. 1st. and then writing up a feedback form page sometime after that.

Presently, it's more an excuse to get me to write code which will benefit the current site era's final project. Much like my plans to make a program to replace search.php with a service that few imageboards if any even have, it's an excuse for me to write a server which can recieve... for example... staff applications, more detailed questions about feature proposals, handle anonymous concerns people want to bring up and, of course, get some self reported ideas of who the userbase is.
These self reported user statistics would be taken with a grain of salt and mostly used to test if the program is working as intended while most other surveys would be mostly text inputs with some multiple choice.

It would be placed in the location of the friends section (related image) so there's always a way to get to it. Maybe it could be put in the footer as well (related image) like 4chan does.

https://github.com/ECHibiki/Kissu-Feedback-and-Forms
Alright, I started the project at last. Large set of test cases.
Admins will be able to design their own forms using the application and will be displayed to users visiting the URL. It will also provide ways for admins to place the forms onto other pages.

>>10558
lol

Been spending the day(and the next) going over documentation and gaining a more complete knowledge over golang's functionality. Normally just wing it and learn as I go, but it's a style with flaws when you need to write something more robust and professional.
https://go.dev/blog/defer-panic-and-recover
neat... this could have allowed me to clean up some mess in other programs I've written.

completely forgot about this post

did you ever post a questionaire?

Uhh, I established this will be part of an application I develop in order to pick up on ideas for the vichan rewrite.

It will come out probably early October or late September. I'm not sure because I'm still in the preparation stage.

The form is nice and all, but I'm doing it as a permanent addition to the site, not a small little Q&A but something for mods or other imageboards to customly create and view

k enough reading... could also go through and relearn a bunch of design patterns, but this project is not hard... I'll do it later for my archive+search feature which I have planned for personal training in clean server dev.

Side note is that my plan is for the forms to be true HTML.
Mod interface will be JS based, but that's not for you all...

Documented all the use-cases,
have project layout planned out,
know which design paradigm I'm following and how it works with golang.
Tomorrow I'll start building the server.

slow progress. Almost done on a basic version of it.
Was pretty useful in catching some misconceptions and establishing good practices.

Finally finished a working version and have it running on the site.
Going to use it in something soon.

Still want to upgrade it but I ought to switch focus to some other items for the time being

source code:
https://github.com/ECHibiki/Kissu-Feedback-and-Forms

Done a respectable amount of development on the features of this tool and gotten some good information on issues that could arise.
I think it would be good to push both this application and the banners application as something other people could use. But I guess maintenance of these features would get backseated to vichan replacement efforts.

There are still a handful of improvements to do with testing and libraries that I want to elaborate on. Expanding on test cases and removing some components for others will be done before getting into writing a major server.
Having these things well understood will pay off in maintenance and development.

- After testing how Twig templates(the Vichan and PHP style of templating) function in Golang I'm going to be rewritting templates from that standard into Pongo2.
Benchmarks say this one of the top3 fastest templating engines in Golang.
- Also I will be expanding test cases to handle fuzzing(essentially throwing random inputs into a function until it breaks or the time expires).
- Also will add in HTTP testing.

After these three tasks are accomplished I will be putting this on idle like the banners program and shifting focus to replacing Vichan with a Golang(Gin+Pongo2+ReactJS) imageboard engine.

Looks like I've gotten everything I wanted to learn out of this project.
Have knowledge of every concept in golang after this. Just will have to expand on it through practice