There's some language inherited from the Eclipse Development Process which doesn't yet map cleanly to the Specification Process, at least in this case. The prime example is the label "committer" for individual. We have to apply a connotation to it that's relevant for our scenario.
> Also by Eclipse rules individuals cannot join as a committer, they need to be invited after experience, but how is that process to occur for document writers (as distinct from coders) who do not have coding experience, The way we intend to approach it is that a committer is someone who's been nominated by a member in some capacity, not necessarily in response to code contributions. When we're talking about language design, particularly a documentation language, code won't be the basis for merit so to speak. (And we don't want it to be). It will likely be content in written form. We can use the charter to clarify this situation, and duly recommend that it be clarified in the EFSP. > or for that matter coders who have no involvement in existing Eclipse infrastructure? No matter what infrastructure is used, someone will have to learn it their first time around. That we can't control. But Eclipse gives us tremendous leeway in what we can use. For example, we can use GitHub or GitLab for the projects (as long as they mirror it). And I'm certainly willing to help anyone who is having trouble. > This is where Eclipse hasn't yet developed the "standards" process sufficiently IMO, its processes are all about software development. It's undeniably an emerging process, but that's also what's so exciting about it. With just over a dozen working groups coming before us, we have an opportunity to influence how the process evolves. Eclipse may learn from the workings of our group as much as we learn from them. You don't get a lot of chances to do that. Eclipse has a long track record of openness, transparency, and inviting new ideas, so I'm confident the group will feel comfortable communicating its needs. > You have stated before that the process for the standards development can be modified, so here is the opportunity to see if Eclipse can accept individual standards participants without them having write access to repositories. Absolutely. And thus far they have been very receptive to our suggestions, so I have no reason to doubt that we can do it. > Also just out of interest, how is it proposed that the "conforming implementation" be developed? That will be one of the key tasks for the Working Group and Specification Process to figure out (though I do have some ideas in my head of how to do it that I'll be proposing). Suffice to say, there will be loads of discussion about it. > I already did, but kept this here in the interests of not making the first thread on the list a negative sounding one Thanks. And welcome! Best Regards, -Dan -- Dan Allen | @mojavelinux | https://twitter.com/mojavelinux -- You received this message because you are subscribed to the Google Groups "asciidoc" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/asciidoc/CAKeHnO4BjL9r5jLFmkmagpSCWViTD1gE3nm8yBp5TLpS7Hff3w%40mail.gmail.com.
