Keeping an announcement post editable might be a good idea. I however doubt it is a good idea to keep something like this open to user comments for a long time. If a thread reaches more than say 20 comments it becomes impossible to read. And keeping a single thread about a plugin open for so long will result in exactly that. With most of these comments becoming deprecated by new plugin releases quite fast. (Most posts in such a thread should go to the version control issue tracker anyways.)
+1 from my side too 
Maybe a good compromise would be to pin an index thread to the top of the category and reference it from the FAQ? Less people would be able to edit the index but that shouldn’t matter that much. It now appears it is a two year stop gap measure until 6 includes a manager. Part of this thought process was started when someone dredged up a post of an ignored announcement. Well, let’s say an announcement that go not immediate feedback. I hate to see things like that get forgotten because no one expresses a current need. That’s why I think we need at minimum an index. I haven’t done the @ ChrisGammell yet because I didn’t want to bother him until we had a consensus we should do something and what that something should look like.
Basically the main idea is that if someone announces a plugin we should do them the courtesy of making sure people know about it since they put in the time and effort to do it. Also, it helps users and hopefully keeps down the duplication of effort so those can be better directed at a new problem or improving an existing solution. Kinda what Source Forge was supposed to do.
1 Like
While I do agree that the thread might (or most likely will) become hard to follow, I’ll take any tester available. Even if it means that I have a thread like in Select tracks by name or net class (I will not guess why the user opened a new topic eventhough the original plugin announcement topic is still opened). Obviously I’d rather handle this within the issue functionality of GitHub (and even there it is hard to convince the users to open separate issues for separate bugs), but as I’ve said I welcome any tester over any channel.
Anyhow it would be nice if the topic is at least editable at least by the user (and some topics are still opened, I guess they were opened before new rules cam into effect)
I sometimes refer users to this xesscorp index, but having one here might be a good idea. Or maybe just point to the xesscorp index, as it is kinda maintained and the owner is glad to take PR. If the community would issue more PRs then the index would be more complete (I have to say that I’ve issued a couple of PRs but I could have done more lately).
I like the idea of a FAQ entry for plugins, or even a sub category for plugins.
(Edit: Oops, sub category alredy exists, I always seem to look over the categories easily on this forum).
Each plugin writer can make a short description (with screenshot) of what the plugin is supposed to do, and make his plugin known to the world.
Having a date with the FAQ entry of the last update of the plugin, and in which versions of KiCad the plugin works would give it bonus points for me.
I think the rules for this would be that posts by users (not plugin announcements) get deleted, and an announchement with the topic rules can be pinned on top of the Thread.
Each plugin can easily have a link to another forum thread to discuss the pro’s and cons of that plugin, so each plugin will get a separate thread for discussing it.
By the way we already have a category for plugins: https://forum.kicad.info/c/projects/external-plugins
I think this is just another example that we don’t know what we know. Many of the answers about plugins are already on this site, but nobody searches for them. Many of the answers are on some external, maintained page, but nobody thinks to search for that. So for all that we know, we’re not able to get that information where it’s needed.
The dedicated FAQ page is an attempt to make some information more visible but, quite frankly, it’s a haphazard list of topics ranging from general to very specific with no overall organization. And making forum topics editable for longer periods in an effort to capture more information in a single thread is not going to make them more visible to those who need them.
In my view, we should be placing more emphasis on search. A Google search of forum.kicad.info usually pulls up what you want. The problem - at least for people new to KiCad and making PCBs - is that they don’t know what words to search for, To that end, maybe we need a simple page that shows the PCB design process with simple explanations that use the applicable vocabulary. Then people could use words from that vocabulary to do an initial survey of possible answers. If even 50% of those questions get answered, that eliminates a bunch of duplicated answers in the forum.
I might even suggest that questions to the forum should start with a list of search terms that were used to find an initial answer before resorting to posting a question. That gives people on the forum a concise summary of what the person is looking for. Then a reply might be as simple as “Oh, just do a search for X, Y and Z.”. And if someone doesn’t start with an initial search, then direct them to the introductory search page and possible give them some terms to start the process.
In the end, emphasizing search over manually crafting the arrangement of the site elements may solve the visibility problem and also cull some of the cruft from the forum threads.
3 Likes
The FAQ isn’t the form I’d prefer but we are learning to work with what we have. It beats cut and paste from local copies every time a subject comes up. @Rene_Poschl in particular has made good use of it. Not everyone that uses a search engine and finds their answer here becomes a forum member so we don’t know how many people do find answers on their own that we never know about.
We aren’t going to change the nature of the way people seek answers and people come here for answers. Plugins are becoming such an integral part of the main program that they are discussing a better way to handle them in V6. I just think we need to do something for the next two years that helps people find the right answers with the minimum of repeats. At the same time we help the developers with visibility. I’m trying to respond to the way the site seems to be growing because in my experience this this is the kind of thing you try and follow, not lead. I think at minimum an index thread pinned to the top of the category similar to the FAQ for now.
I know of at least one example. A few weeks ago i noticed a familiar looking website on the display of a colleague of mine. He had the “how to make a footprint” tutorial open. (And i was not the reason why he had it open. I did not even know that he uses kicad until that point.)
Pointing to announcement threads that are locked but converted to wikies such that plugin owners can update them with release announcements. (Owners can request admins to add their thread to the index but nobody is required to do so. We do not need to give a reason why something was not added. <- this is important, believe me we will get funny notes otherwise. Ok we will get them anyways but we can point to this rule.)
That announcement thread should (or possibly must) include a description of the plugin (best would be a video or at least screenshots), where to find it and how to report bugs and the license of the plugin. The thread itself shall not be used for issue tracking or installation help requests.
Should the tread have already answers in it at the time we lock it then these might be moved to a different thread (should they be numerous enough)
Maybe the mistake is to believe this is an EITHER-OR situation instead of an AND situation.
@ChrisGammell I think we have decided on a general direction so now we can think about the logistics of what the software can do?
Could you please summarize? I read through the threads above, don’t know if I agree that there is consensus.
From @Rene_Poschl 's last post start with the second time he quoted me.
I’m not sure we can mix the WIKI style into the existing category. That would be my question. This is just meant to be a stop gap measure until V6 when they have the plugins better integrated. Assuming the do that of course. 
Sticky an index thread.
Point to announcement threads.
Wikify the announcement posts so the authors can continually update as needed even if the 3 months is up.
OK, sounds good. This is all using the existing category for external plugins?
Yes.
While that is a perfectly fine answer and preferred my most engineers for clarity and conciseness, it isn’t 20 characters.
I also moved the external plugins to be a top level category.
2 Likes
That makes sense for future use once EESchema (and maybe other parts of the package) get an external API for plugins.
Just to be sure i understand the intentions behind it: That thread is meant to get an index post (converted to a wiki) where we make categories containing pointers to different scripts (Categories could be something like BOM scripts, penelizing, version control, …) If this is the case then we should probably close that thread as it will otherwise get hundreds of responses making it harder for people to read. Oh and pin it to the top of the category.
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.