Skip Navigation

Posts
27
Comments
450
Joined
2 yr. ago

Permanently Deleted

Jump
  • Permanently Deleted

    Jump
  • You picked one concern of multiple: Code discoverability of an already known project.

    Multiple times I have found project sources on their own platforms, and when I would have contributed tickets or code, I did not because of requiring yet another account on yet another platform, with whatever yet unknown signup workflow.

    And there is man other concerns, some of which the comment you are replied to mentioned.

  • Pushing commits is just one of many concerns.

    Do you want to suggest synchronizing issue tickets as well?

  • Account requirements seem like a worthwhile safeguard against spam.

    Projects can still use and accept emails or whatever outside of GitHub.

  • I think your dim repo first impression could be improved; with a repo description (there is none), and instead of a description that requires pre-knowledge and one huge example, a more general, novice-friendly description and intro listing positives and short intro examples demonstrating distinct functionalities/advantages.

  • its a javascript UI framework

    a very satisfied field, with a lot of established mainstream options

  • That's a lot of dollars, ching ching ching

  • Later, they comment:

    I've learned today that you are sensitive to ensuring human readability over any concerns in regard to AI consumption

    Their takeaway from

    1. They reject with one of the reasons, and the only disclosed reason, being AI is worse at reading the form
    2. Community says AI readability should not be a priority over human readability
    3. That it may not even be a problem for AI to read
    4. Suggest at least considering an improvement in a form that both can read well

    is that the community wants to "ensure human readability over any concerns in regard to AI".

    I don't think this is only about MS or being overworked. Yes, it was a harsh push-back. But they're responding passive aggressively, claiming the community pushes the other/an extreme when, to me very clearly, it does not.

    Maybe you can say that conclusion is also due do being overworked and not investing the time to read through the comments. But I dunno. There's no need to reply in that passive aggressive tone and claiming unreasonable things.

  • I find that the .NET/C# documentation has great guidance for old and new concepts. There's reference docs with remarks, there's guidance and best practice recommendations, and there's examples and guided work-alongs.

    Personally I've never done the examples or video or text follow-alongs. But I greatly value the concept guidance that goes beyond mere reference docs with remarks.

    While it's somewhat specific to the .NET/C# ecosystem, I imagine it's valuable beyond it, and maybe a good example of how a big and significant enough project can provide more relevant and condensed information than "random tech blogs and websites" or similar.

  • Tell me when you're getting used to USB so I can prepare for the next switch /s 😅

  • I don't see how that is relevant? You're already familiar with C, so writing about C does not influence whether you will be outdated in a few years. Learning and writing about Rust could be something that becomes useful, but not necessarily practically - it depends on what you will do in the future.

    If you feel you lost your passion, I would suggest learning and experimenting with Rust. It's different, so may be interesting and thought provoking to learn.

    Writing down what you know about C may also be worthwhile, good, or produce a good resource, but I don't see it as much or like as sparking lost interest and passion. If that is actually your goal (you only asked about future relevancy in the end).

  • I did not go through those phases.

  • I talked to a friend of mine last week and they didn't know of the old PS/2 mouse/keyboard cable/sockets. They've seen it before, but it wasn't familiar to them. Nobody only having used USB devices will remember those.

  • Who has age authority? A state agency or service. Like the state issues an ID with age.

    Preferable, we want the user to interact with a website, that website request age authentication, but not the website to talk to the government, but through the user.

    Thus, something/somewhat like

    1. State agency issues a certificate to the user
    2. User assigns a password to encrypt the user certificate
    3. User connects to random website A
    4. Random website A creates an age verification request signed to only be resolveable by state agency but sends it to the user
    5. User sends the request to a state service with their user certificate for authentication
    6. State agency confirms-signs the response
    7. User passes the responds along to the random website A

    There may be alternative, simpler, or less verbose/complicated alternatives. But I'm sure it would be possible, and I think it lays out how "double-blind"(?) could work.

    The random website A does not know the identity or age of the user - only to the degree they requested to verify - and the state agency knows only of a request, not its origin or application - to the degree the request and user pass-along includes.

  • You didn't give much info on what it's supposed to be or become, but either one of:

    • Create something of value, while being open and documented enough for accepting contributions
    • Write down and publish goals, approach, structure so anyone can participate, and seek out collaborators while also doing your own
    • AHA - Avoid Hasty Abstractions
    • WET - Write Everything Twice
    • DRY - Don't Repeat Yourself
  • there have been physical fights between committee members

    lol; committee with consensus by violence?