----- Original Message ----- > Hey, sorry - I completely missed your reply :( I'll skip the first part for now and let me more to the docs/marketing team discussion (so heads up docs guys, expect marketing visit on Monday's meeting!). > > What I do right now, I'm trying to revamp feature/change proposal > template, the Feature List and I'd like to "centralize" the planning > and tracking of not only development but also these tasks. > > How could it look like? > > Instead of plain Features List, I'd like to have a clear overview, > generated (I have scripts) from Change Proposals pages. It's very > rough draft! > https://fedoraproject.org/wiki/Releases/20/ChangeSet > > The template could be extended - not only to be change owner place, > but to offer planning/tracking space for Docs, QA, Marketing etc. > See our current draft: > https://fedoraproject.org/wiki/JaroslavReznik/ChangeProposalTemplate > > My question is - what would be useful for your teams to be available > in the change proposal page? What's needed for tracking RNs, TPs etc. > - tracking bugs, ownership etc. I can definitely help here with > coordination - one place for the process from beginning to the end > - to release could make it more manageable. > > > I think at the bare minimum: Having a page that lists Changes (both > systemwide and self-contained) that were "dropped" - and having a way for > both marketing and docs to individually ack that features were removed from > "upcoming" documentation/collateral/"written anything" (that is to say: we > don't want to "retroactively" remove a "change" from an announcement that > already went out). The main idea behind the "Changes" is - these will never be dropped from the list unlike the old "Features", just status will change (aggregated from change bug). Explanation in more details: Features were changes we wanted to market, and at least by current FESCo it was understood as a primary goal. So Feature that missed any deadline were dropped from the list not to market them(!) but still maintainers could work on these, not being a development ban, even finished. But in this case - we lost track. For Changes - primary goal is to track development, from the beginning to the end of release, even Change is not finished in the end. And only selected Changes with appropriate status will be marketed. That's the main semantic difference between these too kinds. > Notification could either be a ticket, weekly mail that has a list of "adds" > and "subtracts" to changes (subtracts going in a page of "removed changes" > or etc), or something else. And then have a checkpoint near alpha/beta/final > change deadlines for individual teams to double-check the list for any > changes/subtractions to the feature set, and make sure those removals aren't > being written about. I like the idea of weekly report/notification - as I said above, I'd like to avoid calling it additions/removals but more status change. I'd be definitely happy to do it. > The sticky part here is that once we get into beta mode, release notes have > to be ready well before the deadline where we'd know features got dropped - > things are moving from wiki to publican, and then they have to be > translated, so anything dropped after that point not only needs to get > tracked back through marketing and docs but also translations. Ok, it's true. With Docs team we decided to follow the same process as for development - to have a tracking bug (that will block the development one). Then it should be easier (if done properly by everyone involved) to see the changes earlier and notify people. So let's meet on Monday ;-). Thanks Jaroslav > I'm not saying it's perfect, very theoretical for now - but we can > be flexible, there's not so much time for Fedora 20 but it can be > on going effort - to make it better and perfect one day ;-) > > Robyn, sorry - I don't want to kidnap your topic :) just it's one > part - the wokflow, how. > > Thanks > Jaroslav > > > Basically: Seeking feedback? Thoughts, anyone? > :D > > > > -Robyn > > -- > > marketing mailing list > > marketing@xxxxxxxxxxxxxxxxxxxxxxx > > https://admin.fedoraproject.org/mailman/listinfo/marketing > -- > docs mailing list > docs@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe: > https://admin.fedoraproject.org/mailman/listinfo/docs > > > -- > marketing mailing list > marketing@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/marketing -- marketing mailing list marketing@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/marketing