Daily Tildes discussion - please help find omissions from the issue tracker
I'm continuing to inch closer to finally open-sourcing the site, and one of the aspects of having it open-source is that other people will be able to start contributing fixes/improvements/etc. To keep this process organized, I want to treat the issue tracker as the "definitive source" of what needs to be done, who's working on it, etc. A lot of the existing plans and known issues are already in there, but there are certainly some things missing.
I'm not expecting anyone to register a GitLab account to help with this, but I'd appreciate it if some of you would take a quick look through the issue tracker (which you don't need an account to do), do some quick searches for features/fixes that you know should be planned, and make sure that they seem to be present: https://gitlab.com/tildes/tildes/issues
If you notice anything missing (or aren't sure if it's there), please just leave a comment here about it, and I can make updates.
Thanks, any help is appreciated (and if you have any other general questions about how the open-sourcing/contributions/etc. are going to work, please feel free to ask as well).
@chase, we're getting closer to open-source. Thought this might be of interest to you.
If you were trying to notify him of this, unfortunately https://gitlab.com/tildes/tildes/issues/96
Maybe @Deimos should have a teaser trailer for the open sourcing.
Will tildes follow semver? How will updates be released? It'd be interesting to see topics like "tildes 1.2.4 is now live - here is the changelog" on ~tildes.official
I don't think there's any reason to version a web app. Features/fixes can be pushed individually, there's no need to do a "release".
The only reason I can think of for versioning a webapp is for external contributors' sake. If the version is displayed on the site itself, and tagged in Git, then it makes it very clear what version of the code is currently running. That way code maintainers can avoid questions about "why isn't my merged PR showing up on the website yet?"
Edit: Then again, you could do the same by referencing a git commit hash on the website, rather than giving full-on version numbers. If that is what distinguishes a "release."
True, though I think I'd probably just use the datetime of the most recent commit and/or the commit's git hash instead of a version number.
I suppose the only part that would need semver would be the API.
Off the top of my head, I'd add an 'investigate'/'help wanted' issue for accessibility testing -- it seems to come up often enough and is a worthy goal.
Looks fairly complete to me, you already have user pagination, user notifications, retain link after login etc...
Not sure if it is just me, but it took me a while to figure out the link to upvote posts was on the right, and the way to upvote comments was on the left - both using a different UI pattern.