List of new features needing documentation?
I'd love to help document new features. Other than monitoring SVN change logs and issue tracker status changes and trying to piece together what's being added that way, is there some sort of running change log at the feature level? What's the process going to be here? Is it just a case of "you implement it, you document it or find someone to do it for you?" If so, consider me available, although time is tight until the end of the school semester. Or, if it's matter of people wanting to work on documenting needing to just get moving, I need to know where to begin. If it makes more sense to wait until things are farther along, that's fine too. But still, a running feature list seems like it would be useful, if it doesn't exist. Such a list would also help in terms of making additional feature requests. Based on my experience with 1.0 thus far, I have a list of things I wanted to see added, and as I checked against the trunk, I saw many of these there already, so I was able to cross them off. But some things that had actually been implemented already I didn't find because I didn't know where to look or what they'd been called. I realize there's no real formal roadmap, which is fine, but I'm not sure what *does* exist.
Comments
There are several questions here :)
First, it's better not document a feature until we are pretty sure the feature will be part of a version and the feature is stable enough. As you can see at the end of the [[nodetitle:handbook]] , there are 3 features for 2.0 with some documentation already.
A list of new features in the trunk can be interesting but with a bold statement that they are in the code but might not end up in MuseScore 2.0 if the feature is not stable enough. We got the case with the chord name editor. The chord editor is included in MuseScore 1.0 code but the menu item has been hidden. (Maybe we should have done this with text styles...).
For last releases, such a list has been compiled a couple of weeks before the release (see for example : http://musescore.org/en/new-features-musescore-096) but it can't hurt to have one sooner if, again, it's stated that it's draft and not relevant for the current version etc... Based on this list, it will be easier to define which part is stable enough to get a new handbook page.
In reply to There are several questions by [DELETED] 5
I agree, no sense documenting something that isn't fairly well certain. And no point putting anything in the actual handbook until it's available in a reasonably stable release. Mostly I'm just trying to make sure things that are being added don't fall through the cracks when the time comes to update the handbook, but any interim documentation that would help testers make use of features added to the nightly builds would be useful in itself. I don't mind writing up stuff for that purpose that may turn out to be throwaway - I figure that's no worse than most of what I might post to the forum anyhow:-)
BTW, I had seen, but had forgotten about, the Milestones page. That's exactly the sort of thing I had in mind, and I love that it records both some of things planned as well as some of what's been implemented already, but it's extremely incomplete on the latter count at least. Similarly for the section at the end of current 1.0 handbook.
So I guess I'd still encourage the development of a running log of new features / changes from 1.0, whether as part of the Milestones page or elsewhere. I think this would benefit testers now and in the future, and documentors in the future. If the only reason this hasn't happened yet is lack of resources, I am willing to help maintain this log. But if people think it really just doesn't make sense until things are farther along, that's fine too.
In reply to I agree, no sense documenting by Marc Sabatella
Typically, what happens now is that just before the release of a new MuseScore version, a few of us go through the changelog as well as the issue tracker and list up the new features and bug fixes. This then becomes the release notes. Given your request, I don't see why we wouldn't do this on the fly.
As lasconic pointed out, there has to be some reservation to write about experimental features. It's normal and even necessary that Werner experiments with new ideas and tries to conceptualize them in the trunk. Often these features are not requested by anyone, but personally I believe he likes to challenge himself and find out whether his data model remains intact or is extensible enough. But enough said about this.
What I would propose is to create a new book page, outline it in the developers handbook and use it as a scrapbook. I like to see it as a more human readable version of the Changelog and ideal for people who are really interested to stay on top of the MuseScore development.
How to create a page in the developer handbook:
- go to http://musescore.org/en/developers-handbook
- and at the bottom follow the 'create child page' link
In reply to Scrapbook by Thomas
I've gone ahead and created just such a page:
http://musescore.org/en/developers-handbook/scrapbook-feature-changes-a…
I'm kind of going out on a limb with this, and if people don't find it useful (or even counterproductive), or think the idea needs adjustment, by all means, take the page down or make the changes. I primed the pump with one of the new features I noticed added recently. I'm kind of figuring that developers are not going to be in a hurry to go back and list features already added, so I'm happy to do some of that myself if people don't mind. But I am hoping to see this page take on a life of its own eventually.
BTW, I did this separately from the Milestones page because it seems to me that this is being used used more as a roadmap of planned changes - especially ones that address major functionality areas - than as a record of every new feature added. But I have nothing against simply adding a more complete list of new features to the Milestones page if people think that's a better idea.
In reply to I've gone ahead and created by Marc Sabatella
The milestones page is focused on things that aren't in MuseScore yet (although over the course of one development cycle somethings will be marked as complete).
Originally I started it as a way of highlighting what I saw as the most important (and doable) out of the large number of bugs marked as "normal" in the issue tracker. So my intention was the opposite of "comprehensive". It was also a way of grouping bugs that all related to a particular user task (i.e. ensemble scoring, or lyrics).
In reply to The milestones page is by David Bolton
Your description of the intent matches my impression of the reality quite well, so I'd say it's a success on that front :-). Which is why having the running list in a separate place strikes me as the way to go.
My thought on the scrapbook page is that I will go through and find some of the most significant changes that have been in the trunk the longest and seem the most stable, and get them listed gradually. Even if no one else finds this page useful, I think *I* will. I'll try to err on the side of caution regarding freshly added features, although if I see people closing out feature request issues as having been resolved by some change in the trunk, I'll probably take that as a sign that's worth listing.
In reply to I've gone ahead and created by Marc Sabatella
Very good initiative Marc! You have all my support.
You may not have seen the Milestones page yet. David maintains it currently to keep track of features. Maybe you could collaborate?
I agree with Marc, where and how to begin is my main question. As a musician and music teacher, this project is the best thing I've come across since the days of Atari's Notator..... I find most music programs become overly complex as the publishers continually strive to upgrade their product over the competition. They then become cumbersome and expensive.
This is definitely the way, goodbye "Logic" , "Finale" and all the others.... but how can I help here?
I see the need for some tweaking in the handbook, terminology for one, as it differs from country to country in the language, let alone what could be lost in translation. The updates are great, but should be incorporated into the handbook ASAP after approval, (by who?) also why can't they have the same page format as the handbook, that way they can be punched and added in the same binder for reference.
Using Version 1.0.0 with a 0.9.2 handbook needs correcting, also general midi standards should be complied with, where possible.
I have looked for items in the handbook only to find that the were not included, but then they show up on the menus of the program, exactly how to use same, is another question.
Enough said, I'm ready
In reply to Documentation by woodside31
FWIW, I'm a former Notator user myself. Was stuck using Finale the last 10 years or so, but never really warmed to it the way I did Notator. I do appreciate a lot of the features Finale added over the years - but many of them were needed just to catch up to where Notator was in, what, the 1980's? Whereas Finale seemed bloated and clunky right from the beginning, even when it was more limited than Notator in many ways. Although I guess in some ways that did indeed get worse even as some of the changes were for the better.
Anyhow, everyone seems to agree the handbook needs work, but I'm not sure if it makes sense to do a ton to it based on 1.0 or whether it makes more sense to instead look toward the next major release, which is probably still a ways off but seems like it will be different enough that it may require a lot of rework in the handbook. My inclination is to maybe add or flesh out a few handbook entries here and there for now where something important seems obviously missing, so the 1.0 handbook can be more useful than it is, but do what we can to make sure the next release is documented as well as it can be.
I haven't yet gone through and added anything to the "scrapbook" page I created, although I see Werner has added a few things. I am hoping to take a look at this after next week. My own focus of late has been on chord symbols and lead sheets in general, and I'm getting ready to post a tutorial.
In reply to Notator! by Marc Sabatella
Looking at the Plugin drop down for Chord Symbols scares me no end, if you have to select from the massive number of chords available for just A , or maybe I am reading this wrong. This is one of many items not covered in the handbook which if we aren't careful will become a manual of many volumes similar to "Logic".
I hope a more simple concept is being considered using selective choice. Such as the Initial 7 for the notes followed by 2 accidentals + a blank then follow with standard symbols such as M, m, dim, aug. or O, +, 6, 7, etc.
There is also a standard system of chord naming that seems to change in concept yearly, which needs addressing and is the instrument not a consideration also? Lead sheets don't discriminate, EG: should we have Cm/A or is it Am7b5 then again maybe Cm6, it depends on how much of a purist you are and if you play bass, piano or guitar. Then again maybe a split in style would help .....Classical, Country, Pop, Rock, or Jazz
Larry
In reply to Chord Symbol thoughts by woodside31
I think you *are* reading it wrong. Enter the chords is supposed as simple as just typing them; you don't have to select from a huge list. That list is just there to let you what the options are. If you try typing something not on the list, MuseScore won't recognize it, and therefore won't treat it correctly (it won't display correctly, it won't tranpose, it won't be exported to MusicXML, etc).
However, you'll note that the list of recognized chords, while huge, only includes a single way of spelling each chord. That is, you don't get to choose whether minor seventh chords are written as Cm7, Cmi7, Cmin7, or C-7. To address this, I recently created my own customized version of the XML file that controls chord input and output, and posted it in this thread:
http://musescore.org/en/node/9772
The XML file I posted there allows for "easy" customization of your chord symbols, which would allow you to create your own different versions for different styles or different instruments if you wished. Looks like the next major release will go further in this direction, but I think you'll find my XML file a big help if you are looking for more flexibility with chord symbols now.
In reply to Documentation by woodside31
woodside31, the English handbook can be edited by anyone logged in to the website. The online handbook is updated immediately after editing. The PDF included in the software is a copy of the handbook as it existed at the time the software was released.
If you plan on making large changes to the handbook you might consider discussing it before hand on the forums