[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[cross-project-issues-dev] Counting Indigo Projects
- From: Wayne Beaton <emo@xxxxxxxxxxx>
- Date: Wed, 15 Dec 2010 12:43:25 -0500
- Delivered-to: email@example.com
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7
Hey folks. Sorry, this message is a little longer than I hoped. Please
read this if your project is participating in Indigo.
Last year, it was very difficult to determine participation numbers .
Depending on how we counted, there were four very different numbers. I
think this makes us look a little silly.
This year, I expect to receive exactly one IP Log and one review
document for each project that has opted in. More specifically, projects
that are participating at an aggregate level should provide me with one
IP Log and one review document that includes information for all the
aggregated subprojects. Recall that we asked for a short description (~
one paragraph) from each project last year. I believe that this was
valuable and think we should do it again this year. Let me know if you
have a different opinion. Again, I expect to receive one paragraph for
each project that opts-in (I'll set up a wiki page).
Web Tools, for example, opts into the simultaneous release at the
top-level; they provide me with one roll-up IP Log and one combined
review document for the many sub-projects. The Tools project is
different in nature, and instead lets its projects opt-in individually,
with each providing its own IP Log and Review documentation. Both work
fine, let's just keep the manner in which we participate consistent. In
my mind, if you are opting in at an aggregate level (say a second-level
project aggregating several nested third-level projects), then that
means you've probably got a shared build and provide shared downloads.
If this isn't the case, then this might be a really good time to rethink
your participation strategy. Of course, this is just how I think (and is
merely a guideline), and I defer to the wisdom of the community and
If the provided tools are a problem let me know (I hope to release the
new and improved IP Log Tools very soon). If this just isn't practical
for you, then maybe you're not participating at the right level.
I am prepared to help you start getting your IP Log and release
documentation ready now. If you're not sure if you need a CQ, need some
help determining how to mark bugs and patches for inclusion in your log,
or have other process-related questions, let me know. Incubating
projects can also engage with their Architecture Council Mentors to make
sure that this gets started early.
Please make sure that your project plans are up-to-date. Please also
ensure that your project's Indigo release is indicated in the Developer
Portal with appropriate links to your new and noteworthy and
(eventually) approved IP Log. While you're in the portal, please also
make sure that your project's descriptionurl and paragraphurl fields 
point to simple HTML documents containing a medium-length and short
(respectively) description for your project. Neither of these fields
should contain a link to your project's website (doing so makes your
project's summary page look terrible). If this information is
consistently provided, then I have a fighting chance of automating
summary documents and such (and then you don't have to bother with that
sort of thing).
Be aware that the IP team will be making an announcement shortly with
regard to cut-off dates for IP reviews. Get your Third-party library CQs
for Indigo releases in quickly (sooner is better than later).
If any of this causes you concern, please let me know. This seems
reasonable to me, but I understand that there may be mitigating
circumstances to consider (hopefully I've demonstrated my desire to be
flexible and reasonable).