Alright, so let me comment both on Outdoors and Notifyers. The impression that these packages were spam (and why I now initially flagged your Discourse posts) originated from a range of “red flags” from when you tried to register a whole bunch of packages in January.
Some of the things that stood out (in no particular order):
- Newly created GitHub user account
- No real name, no bio or other verifiable information
- No commit history: All packages were created via “upload”
- Registering many packages at once, with no apparent connection between them
- Trying to register a package like
OrderedDict.jl, which seems like an extremely basic implementation of functionality already in OrderedCollections - Varying licenses: it is extremely unusual for humans to randomly switch between MIT and Apache
- Mismatches of author names: “Talom Laël” in the README, “Kaptue Lael” in the Project.toml, niether of which connected to the username (I realize this is probably because your name does not fit the “Firstname Lastname” assumed in much of the Western world)
- Non-sensical “random” version numbers, e.g.
v1.5.0for the original registration ofOutdoors. These package do not appear to be functional yet, so version numbers >1.0 would both be inappropriate and seem unusual to be set by a human - No responses on the registration PR.
- A general lack of documentation
- Unusual code structure with “weird” random files like nothing.txt
- Broken
Project.tomlfiles. E.g. with missing dependency declarations, these packages could not possibly have been instantiated, and thus could not have been tested, or even been used in any serious way - In the only existing README at the time, the broken format and broken links.
- To the extent that the packages had any documentation (READMEs), I felt like the text there was the kind of word salad that early AI models might generate. With some additional context and spending more time with it now, I would now lean towards it simply being poor writing.
I’m not giving this very long list to beat you over the head with it (or something we should be going over point-by-point). This is just the background for how many little red flags ended up giving the impression that we were dealing with an auto-generated account producing spam. There was also the context that we have seen some “pen-testing” in the last couple of months on the Julia infrastructure, where people similarly “spammed” the registry or other channels with automatic content. This seemed to potentially be a part of that.
I am 17 years old and I started programming just 1 year ago. I’m a Cameroonian and I have limited resources and since my computer stopped working, I didn’t have an environment to properly publish my package.
gives a lot of new context for how these “red flags” actually came about. Thank you for that! I can definitely see how a lack of experience, cultural differences, and lack of resources would have gotten to this situation. The Julia community has pretty high standards that are very much based on particular, GitHub-centric workflows, and standards of programming/testing/documenting that are very much rooted in the “best practices” from the European/American world of academic scientific computing. You probably do have to get familiar with these best practices to really grow into the Julia ecosystem. There’s quite a learning curve, but I would like to encourage you to follow that curve. I would also like to explicitly apologize for mis-labeling your contributions as spam.
As for best practices, I would probably recommend starting with the Modern Julia Workflows page. I would put a particular emphasis on documentation. Apart from the code “working”, there’s nothing more important than how you document it. Generally, I would encourage people to internalize the philosophy that seems to now go under the name Diátaxis (what used to be simply the great talk “What nobody tells you about documentation”). The whole system is for bigger and more mature projects, but it’s worth to start thinking about these concepts early on. For a project that’s just starting out, a README is usually perfectly sufficient. But even then, you have put some effort into the writing, and have a clear structure. Sit down and write yourself an outline for which points you need to make in which order to give a random Julia user an overview of what your package does. Usually, that means you should start the README with an explanation of the background and purpose of your package, targeting an “average Julia user”. That is, someone who doesn’t have any context for what you’re working on. You may have to define some basic terms and concepts, and state the “problem” and the approach you are taking. Avoid jargon. The README (assuming there is no full documentation) must also give a starting point for using the package. That is, a small usage example, maybe some screenshots if there is any graphical component. Basically, just by looking at your README, I should be able to figure out what your package does, and I should be able to test it out. That is pretty much the requirement we have for registration of packages in the General registry – and, probably, also the minimum for when it makes sense to “announce” your package on Discourse here.
If you emulate what you find in any recently registered and somewhat widely used Julia package, that should be a good start.
I noticed that you started a README for Outdoors.jl yesterday. While I don’t want to be too harsh, I would say that the “Intro” text there,
Outdoors is a package made to create manage windows in an elegant way without bothering too much about the API used. It abstract API specific instructions and create an unique interface for all of them. the package has currently the SDL mode but implementing GLFW windows shouldn’t be much of a problem
is not something that strikes me as “good writing”. I might even have put it in the “word salad” category that raises my LLM alarm: sentences that seem to make sense at first glance, but don’t say anything once you pause to think about it. So I would definitely recommend making a dedicated effort to improve your technical writing skills. But look: You’re 17. I couldn’t write anything coherent at 17. That’s okay, you have lots of time to get better at this stuff. It might mean that your packages aren’t quite ready yet for registration or for being widely used, but that’s okay, too. You can still build something, have it grow, get better over time. The main thing is to have fun with it (and I sincerely hope that my criticism here doesn’t suck the fun out of it).
But just to give some feedback on that particular paragraph: First, it’s unclear what “window management” is about. Are you talking about a GUI framework like QT or GTK? Those are huge endeavors: GUI frameworks are not something that are feasible as a hobbyist project. So is this a GUI framework? Something that sits on top of an existing GUI framework? What is the context here (you mentioned “gaming” earlier)? You’ll have to give a lot more background. The next sentence “It abstract API specific instructions and create an unique interface for all of them” makes no sense to me. There are obviously some grammatical mistakes (nobody’s perfect, but spelling and grammar matter, and it’s a good idea to put in the effort), but also, what does “them” refer to? In the last sentence, “SDL” and “GLFW” are not widely known acronyms. So that would be something to give more background on, and/or to link to other resources about.
I would have similar issues with the README of Notifiers. You should probably spend a paragraph explaining the observer pattern. You’d probably want to summarize the philosophy that you see in the Reactive.jl and Obervables.jl packages (fix the links!), and why and how you would like to “fuse” their concepts. Likewise, summarize what exactly in the Godot game engine inspired you for this new package. What’s a “polyvalent solution”? (That’s not really a word outside of chemistry.) Presumably, you mean that in the metaphorical sense, solving several problems with existing designs, but it’s not clear to me what exactly those problems are. Also, it’s a bit weird to have “state” as the central concept of your package, but then say “Also, I am a bit hesitant on letting people create states, since the interface of a state is a bit complicated but if you really want to create a state, just let me know it as bug report and I will try to simplify the interface.” (that was one of the things that raised my AI alarm). At least, that’s an indication that the package isn’t quite ready yet for public consumption.
Anyway, sorry for the long post and potentially harsh criticism. After incorrectly flagging you as spam both here and during the registration attempt, I felt like I owed you some really detailed feedback. Please don’t let it overwhelm you or discourage you from further engaging here. I think it’s great that you are engaging (since you didn’t during the registrations, and that was a major point for it being flagged).