streams-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suneel Marthi <smar...@apache.org>
Subject Re: [DISCUSS] Community - call for help [Was: Setting priorities for our next few releases]
Date Thu, 29 Sep 2016 22:46:37 GMT
Hi Ate and Steve,

I will be glad to contribute code too and be more involved in keeping the
project moving. If u could point me to jiras I could tackle I'll get
started on that.

Suneel

On Thu, Sep 29, 2016 at 2:26 AM, Ate Douma <ate@douma.nu> wrote:

> Hi Steve, community, silent followers,
>
> In general the proposal and suggestions from Steve are all good steps
> forward.
>
> But I'm for now top posting and forking that discussion to try address
> everyone
> in the community directly, because I think there are other and more
> critical
> actions needed to make clear to the Incubator PMC that cancelling of this
> project retirement will not end up to be just a temporary pause.
>
> The first and highest priority action should be getting more and diverse
> involvement and active participation from the community.
> The steps suggested by Steve are definitely helpful and needed as well.
> But it just as well might end up remaining a one man's task list...
>
> Instead, we need to get more active input and suggestions/questions from
> others
> in the community, like Joey, our new mentor Suneel, and hopefully as well
> from
> the W3C ActivityStream 2.0 working group people, like Benjamin Young.
>
> And we need not just 'talk' feedback, but actual interest and participation
> with concrete contributions.
> (Suneel: I know you signed up just to mentor, which of course also is
> needed)
>
> We need to see and show serious promise for growth of the project
> community to
> the IPMC, and in a reasonable short time frame (a few months at most).
> Without that I think the changes of getting this project back on its feet
> will
> remain unrealistic, and then better be stopped.
>
> This also was indicated by the request from John Ament (the Incubator
> Chair), to
> switch back to monthly reporting for the coming 3 months, so the IPMC can
> monitor the progress and chances for success. And if not, probably will
> decide
> (or at least vote) for a final retirement after all.
> I agree with John this make perfectly sense, and I'll update the reporting
> schedule for Streams shortly to make it so.
>
> Meaning: a next Incubator board report will need to be delivered monthly
> for
> at least the coming 3 months.
> We better make sure there is positive news to report :-)
>
> I also cc'ed Benjamin Young (who AFAIK hasn't subscribed to this list)
> to see what ideas he has and what concrete actions can take in getting the
> W3C
> ActivityStreams 2.0 people involved as well.
>
> And I'm explicitly calling out to the mostly silent community, including
> the
> other committers, to speak up and let us know what you might be able to do
> for
> the project *now*: ideas, feedback, testing, maybe even code contributions?
>
> Kind regards, Ate
>
> On 2016-09-28 22:00, sblackmon wrote:
>
>> All,
>>
>> Joey brought this up over the weekend and I think a discussion is overdue
>> on the topic.
>>
>> Encouraging community growth and performing regular releases are on our
>> list of graduation criteria.
>>
>> A few easy behaviors we can adopt to take to make progress on these goals:
>>   - planning release versions around one or two significant improvements
>>   - setting target dates to kick off upcoming releases
>>   - prioritizing our backlog after each release
>>   - discussing project and community milestones openly on the list
>>   - organizing JIRA so that all contributors (especially new) can decide
>> where it’s most important to focus their efforts
>>
>> I think to get things moving again and demonstrate we are capable of
>> consistent progress, we should aim to perform a release once per month
>> around the end of the month.
>>
>> As for what to focus on, I think it’s time to discuss adopting Activity
>> Streams 2.0, figure out what form that transition would take, and get
>> started down that path.  Working implementations demonstrate the
>> suitability of the standard and drive it’s adoption, and the prospects of
>> this project are closely tied to those of the standard.  Separate DISCUSS
>> coming on this topic.
>>
>> Also important for the ‘reboot’ theme, we should delete any modules we
>> aren’t going to maintain, and bring all modules we are going to maintain up
>> to acceptable standards - exactly what that means is an open question but
>> broadly they should have documentation, code comments, and tests at the
>> level of a typical module in a typical TLP.
>>
>> Expanding the examples to demonstrate how to use streams providers and
>> processors within various execution engines and fixing any bugs that have
>> been reported is desirable as well.  Adding at least one new example per
>> release is a good target for now.
>>
>> I have created some future versions with target release dates in JIRA and
>> invite all committers to associate existing or new issues with those
>> releases, or anyone who can’t modify JIRA to summarize their thoughts and
>> share with the list and I will incorporate those ideas into JIRA.  This
>> should be the default reference for anyone looking for a way to help - look
>> at issues associated with the next few releases and the top of the backlog
>> and pick something that appeals and is in line with your experience.
>>
>> Anything else that should be a top priority for the rest of the year?  Or
>> other ideas on improving planning and coordination?
>>
>> Steve
>>
>> On September 24, 2016 at 1:01:02 PM, apache (sblackmon@apache.org) wrote:
>> - This has already come up, but maybe ActivityStreams 2.0 support would
>> broaden the community and motivate more work. It's also a concrete
>> goal to work toward so people would know where they can start.
>> - Steve and I did a little work here a few months ago, but the JIRA could
>> reflect the priorities better and I think keep the community working in a
>> common direction.
>>
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message