Userdoc has versioning of stories and acceptance criteria, aimed to at helping this exact issue https://userdoc.fyi (transparency: I’m the founder)
219 karma · joined March 10, 2010
I started writing little scripts to boot annoying people off IRC, but ended up caring more about coding than IRC politics - and ended up writing a full blown Napster clone in Tcl.
I feel like I owe my career to Tcl opening these doors for me - so thank you John.
Loyd Blankenship, better known by his pseudonym The Mentor, is an American computer hacker and writer. He has been active since the 1970s, when he was a member of the hacker groups Extasyy Elite and Legion of Doom.
My B2B SaaS Userdoc is going well, but certainly not at the growth level of those AI image generation apps I see all over Twitter
E.g. If the DB table had 500k vectors, but you were pre-filtering by WHERE client_id = X (returning only 200 rows) then with an AND <embedding search> (returning only 6 rows) - would this still have the same performance issue?
Or is it literally if the embedding search is over 500k rows?
By segmenting data, is this as simple as adding a further condition to the SQL? E.g. if your embeddings belonged to a "client" you would start with WHERE client_id - x?
> How you chunk text matters. Chunking by paragraph is much better than naive chunking
Would love some more info on this. SO if you had a 400 word slab of text, it would be better to create m3 or 4 embeddings from that?
https://learn.microsoft.com/en-us/answers/questions/1305032/...
E.g. A Jira ticket moves to "Done", the requirement is complete, and people are happy. But the important info on that ticket has essentially disappeared - obviously you can mine your thousands of tickets for historical info - but no one really does.. as it's mixed with bugs, changes, improvements, conversations etc.
But as the author mentions, Jira contains tasks related to bugs, text changes, colour changes etc.. These are not product requirements per se.
Like the author, I came to the conclusion requirements are best kept in a requirements management system, that integrates with your project management tools - a source of truth and living documentation about what the product does. (Not conversations back-and-fourth about bugs and UI minutia).
And like the author, I have also created a requirements management system https://userdoc.fyi (currently we are specifically focused on user stories, personas, and journeys).
Customers have saved days using Userdoc, whether that's to help them flesh out the requirements they already know, or generate requirements they couldn't come up with themselves.
After running a development consultancy for 8 years, I wanted a dedicated system for gathering and confirming requirements, and only syncing them with project management tools like Jira when they are ready (but keeping them in Userdoc as the living documentation and source of truth.
Things are going well, we have some large enterprise and government clients - and a two week experiment with AI back in January has lead to infusing AI into most aspects of the platform, which has opened up a lot of doors.
I ran my agency for 8 years, and we had a small clients, but worked on large complex projects.
I started with Google docs, then Confluence, then Notion - but I could never find a tool suitable (and opinionated) enough for capturing all this info.. as I really wanted to build a map of the system in docs, that was easy to reference when the next sprint comes up.
Userdoc has been designed to facilitate the initial collaboration with the client (user story mapping, personas, journeys etc), but also be a business asset, where requirement specs are iterated on, approved, and kept as long term documentation. As an initial test, we used Userdoc on a very large government project, and it significantly helped the whole team.
So where Userdoc comes in is.. 1. The requirements gathering phase (e.g. work with your clients or team) 2. The requirements sign-off phase (get clients to approve the requirements) 3. Sync all requirements into Jira, Asana, Trello - 1000's of other platforms. 4. Testing - you can export documents of all the stories and AC's easily 5. Changes - instead of making new stories for changes, alter the existing AC, and sync 6. Long-term documentation - don't lost your requirements after the sprint ends
I don't need any more domains, and I should probably also give some of mine away!
Agile taught us working software over comprehensive documentation, but it also made huge generation of people thinking that all documentation was bad, and not just "comprehensive" (or "overblown").
Documentation (words) is how many complex concepts are communicated.
I've built a requirements management system to handle this (https://userdoc.fyi), and it's made many projects I've worked on 200% easier for developers, project managers, and all stockholders.
I think high-Documentation is out of fashion as a reaction to agile, but things are swinging back the other way.