[Starlingx-discuss] Proposal: Basic development guidelines / rules
Ildiko Vancsa
ildiko.vancsa at gmail.com
Thu Jun 21 18:29:23 UTC 2018
Hi,
To chime in a little, I would suggest to keep the processes as simple as possible to start with.
StoryBoard gives opportunities to add a description and also comments to a story so it can be a good forum to start with. You can always define a template to follow and/or use Gerrit for new specs later.
Starting with simpler processes will help new comers to join your community easier which is extremely important in this phase. You can evolve the processes as the community grows and you identify bottlenecks or some missing steps.
Thanks and Best Regards,
Ildikó Váncsa
Ecosystem Technical Lead, OpenStack Foundation
(IRC: ildikov)
> On 2018. Jun 21., at 19:58, Chris Friesen <chris.friesen at windriver.com> wrote:
>
> On 06/21/2018 11:27 AM, Dean Troyer wrote:
>> On Thu, Jun 21, 2018 at 10:26 AM, Jones, Bruce E
>> <bruce.e.jones at intel.com> wrote:
>>> Dean - for larger changes, do you recommend we adopt a spec writing (Blueprint) process? If so, how would that be done?
>>
>> We need to do something to review design and implementation.
>> 'blueprint' is a launchpad term that is now overloaded in akraino so
>> let's not use it.
>>
>> Some Openstack projects added a spec process, including a specs repo,
>> to iterate on the design and implementation and worked that in
>> Gerrit. That is not the best forum for some kinds of discussions so
>> those often got held in Irc or the -dev mailing list. And some
>> projects used both specs and blueprints.
>>
>> This is one area that I think we need to suss out what we actually
>> want and not just fall back because there is no clear single precedent
>> to borrow. At this point a single collection of documents and review
>> process seems sufficient, we could manage them via Storyboard or
>> follow the specs repo format. I don't have a strong opinion there.
>
> As I see it, the main benefit of an OpenStack spec is that it goes through Gerrit and thus lets people review and comment on the iterations of the design. It also lets you go back years later and maybe figure out why things were done the way they were.
>
> I think that it's valuable to allow people to comment on in-progress designs, so as long as there's some way to do that I don't care about the exact mechanism.
>
> Chris
>
> _______________________________________________
> Starlingx-discuss mailing list
> Starlingx-discuss at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
More information about the Starlingx-discuss
mailing list