Today i realized that i can’t ignore minor feature requests, but i should! Because in this case we will never see the next major release.
And from today i propose to close “the proposal window”. No new features from outside will be included in 0.5.0 roadmap. All proposals will be moved to the next future releases despite how small and trivial they are. But we will make exclusion for pull request from contributors.
Instead we will continue to work with features from roadmap and fixing bug reports.
We must have the notches and grainlines.
We can’t wait another 6 months before these are in the release.
These two features plus the labels on details were supposed to be the basis for v5.0.
Who knows why, but this sentence is not clear for all. I will repeate myself. I will merge pull requests from outside, but i will do only features that are already in the roadmap for release 0.5.0.
I think this is a great idea. I think if you release V5 with the current roadmap, you will get a lot more people involved and using Valentina. As far as I can see so far, V5 will have enough features to get patterns done without having to take the patterns into another software like inkscape, which is a real hassle in V4. The rotation tool alone has made a huge difference, and if we can put grainlines and knotches etc. it will be great. Cheers
Cheers Carol
Make sense to freeze the features and get on with the process of developing. If features get pushed to the next sprint(etc) then that is a function of users getting feedback quicker and being more precise and measured in their expectations. Let the development process take place at it’s current pace, and then be happy that there is a process to develop that can be built upon.
Possibly focus in on a higher level within the development process and use this feature ‘cull’ / line in the sand as an opportunity to better think through how features get importance placed against them by a skilled audience, maybe a simple star rating and listing that give greater visibility that has discussion attached so the thread of thinking can be followed more readily from both the user perspective and from the developers perspectives. (line up can do this easily)
Valentina have just moved to this new forum platform, so perhaps use this new mechanism/space to support wider connected input, earlier and with indepth feedback. I suppose what I am suggesting is treat this as a solid learning curve as you transition into smoothing out features relative to development cycle improvements, and then accept cut off points as opportunities. This could be a point (new forum) to widen out the discussion on notches and to also get some overview on the technical difficultly, and resource commitment needed to achieve that goal. Transparency.
Ref: notches, I have to disagree here as to how critical these are at this point. Technically notches are based on line lengths that match between patterns - these are typically set at nodes or a change in linetype geometry. The current drafting allows for this ) In other words they technically can be set in a next workflow if moving to CNC cutting - and if printing it’s not too hard to align pattern pieces untill this feature comes on stream. If one uses the current output, they can simply apply a notch insertion point on a change in line type geometry (node) - for example in inkscape this can be done on a seperate layer assigned to CNC cut layer by inserting a symbol.
If the notch is simply for visual reference, then I fail to see the need at this point unless it is tied to full line length between notches. Notches need to be well considered in the wider spectrum of geometrical integrity, how they get passed on in terms of machine data language.
OK - new to this forum so I am just trying to get a handle on the development landscape. I am away on Biz for some weeks so I will respond when time permits.
No problem, your forum posts are good, please post your thoughts here. And when those thoughts include specific info relative to the implementation of a feature, we will usually ask if you would like to add your comments (copy-past is fine) to that feature’s issue on Bitbucket.
Valentina is open source, the community is part of the development process. Features are developed per user request and to user specifications. Issues should include user perspectives, requirements, etc.
Are you sure about that?
I would view a feature freeze as a way to limit review and testing as well. The general concept of alpha - beta - rc - final uses the Idea that after beta no new features are added at all, wouldn’t it be wise to follow the same principle (even if no alpha and beta releases are made)?
And I personaly am a fan of small and fast releases, which makes it easy to focus on a small set of changes/features and push new ideas to later (but soon) releases.
I’m sure you are fully capable of handling this well, I just wanted to throw in my thoughts for consideration
No. This is feature freeze only for me. Decision only from my side to begin saying for people NO. Sorry, but this cool/easy/nice/small whatever feature will be implemented only in some next releases.
This is true only for finished, after v1.0, products. In our case i hate situations when i release new version and people ask me “can i begin work? Can i now make patterns?” And i still answer kind of.
So, by beginning my “feature freeze” i am saying i will not do anything that is not in the roadmap. But if someone will send PR i will merge it, because i did not spend time to make these changes.
Maybe there needs to be a definition on what constitutes " use of Valentina" in a number of end user stories so that people can focus on a range of project outputs. It might also be a great way to push those whom are not coders to develop artifacts (patterns and style variations) at the project level that let new users see how that version can be deployed, along with it’s limitations. And maybe it should be structured in a new way.
Garments and pattern designs should be able to be placed on a resource like GITHUB under a similar control. Such that users can fork the garment/pattern and develop it as new versions of software features roll out. That could also be tied to standalone measurement systems, that people develop alongside > for example customer input. Ultimately that might be rolled up into a tool inside the software (linux) so you update two versions and project garments/measurement fit.
@245oldsalty, sorry, but this thread is not appropriate place for such discussion.
Any limitations come from our own experience limitation. So, the authors is the main source of limitation here. I agree with you that for us better to avoid such limitation, but you can’t tell a story if you don’t know it yourself.
So, there is no such thing as a list of end user stories. And never will be. I have better plans where to spend my time.
This is great idea except one thing. We have not such people. From time to time users show us own patterns, but i don’t see any chance to make it possible for now.
Patterns don’t need to be ‘feature’ frozen, so their benefit to the wider project is that they can accrue value as they get incrementally developed, building interest in your project. There is not so much pressure on pattern design as there might be on engineering. In this way you could structure Valentina so that it has a library of ‘design projects’ that act as the catalysts to interest a wider audience, that might introduce more program resources. And that could in turn drive connectivity with a wider user base of ‘stories’ to test features that are frozen.
The opportunity to expand cross-over using the ‘designs’ might be worth considering. Engineering can then plug into that growing market base of consumer stories.
One cannot stick their head in the sand and say - ‘our own limited experience’ … that’s not really the type of thinking at the heart of open source and I am surprised at that comment. I think you just lost any of my further input for this project. Good luck, wish you all well.
If you see so big opportunity right now why not create a fork and prove that i am wrong? This is super easy this days don’t you think? But before you did and before you tried to understand how it works such words pointless.
The open source is about people that work together to achieve own goals. People come to us because want to use the tool we have been building. They bring real use cases that we still don’t cover. They bring tips, bug reports and seek knowledge about the project. The community is a place for sharing knowledge about pattern making.
Be more specific, because right now you are arguing about our management skills and our vision without any real contribution to the project. I know for sure you would not do such thing if you knew what we know.
You are mistaken if you think we have no such thoughts and plans. But we also are realists. We take goals we can really achieve with our resources. Take a look on Linux kernel. Did first developers have understanding how big the kernel will come? No. They have been fixing issue after issue, use case after use case. And after this new people find the project useful for own purposes. They come to the community and make it stronger. Stronger community means more resources. More resources mean more global plans.
So for you we are maybe blind and don’t see opportunities. But we just don’t want to put all our cards on the table. And waits appropriate time for these plans.
Funny, i am not surprised that you did not understand me. All i tried to say was we now have been creating (limited) to things we understand and need (our use cases). And this of course don’t mean we are closed to proposals from “outside”. But we also take responsibility and discard ideas that are not proved to be good. Especially without proof of concept code implementation.
