----- Original Message -----
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
> 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
> generated (I have scripts) from Change Proposals pages. It's very
> rough draft!
> The template could be extended - not only to be change
> but to offer planning/tracking space for Docs, QA, Marketing etc.
> See our current draft:
> My question is - what would be useful for your teams to
> 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
> 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
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
and "subtracts" to changes (subtracts going in a page of "removed
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
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 ;-).
> 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.
> > Basically: Seeking feedback? Thoughts, anyone?
> > -Robyn
> > --
> > marketing mailing list
> > marketing(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/marketing
> docs mailing list
> To unsubscribe:
> marketing mailing list