Hi all, so how about I update the tooling to the latest RevealJS and Asciidoctor versions and then we release that once. Once that's done we should probably encourage projects to reference released versions of the tooling and then I have no issues with allowing full access. Only thing I was a tiny bit worried about would be that potentially many people could be tempted to start modifying the tooling making it a challenge to keep the presentations in a stable state. But if the presentations only reference released versions, that's not an issue.
Chris Am 13.08.20, 14:40 schrieb "Ryan Skraba" <[email protected]>: Hello! I think this would be a pretty good experiment, and an appropriate place for all committers access! The activity on the repo has been pretty low for a while... I imagine summer and working-from-home is a part of that. I'd vote for leaving the repo as it is (including tools) and seeing what happens, but I don't feel strongly about it. We can keep an eye on the commits and go from there. On the other hand, if opening to the world, it would be great to flesh out some extra policy on the README.md or CONTRIBUTING! Things like: * How to create a new slide deck * Guidelines on identifying information (people and companies) in the repo * Checking licenses on images, where to find free images, etc. * Still review-then-commit? Who should review? Who should commit? Should we protect the master branch from non-PR commits? * Do they have to join/discuss on the mailing list? I don't think we have to have all the answers immediately to give it a try! Does anyone have experience with a more open project repo? All my best, Ryan On Thu, Aug 13, 2020 at 7:16 AM Christofer Dutz <[email protected]> wrote: > > So do we want a separate repo for the tools, or all in one? > > Chris > ________________________________ > Von: gautam gupta <[email protected]> > Gesendet: Mittwoch, 12. August 2020 19:48 > An: [email protected] <[email protected]> > Betreff: Re: What are these "Triage Needed" emails about > > I think it'd be good to try this model of providing commit rights to > Apache committers for a time period of 2-3 months to see how this works. > Based on the feedback, we can review it and take decision appropriately. > > thanks, > Gautam > > On Tue, Aug 11, 2020 at 9:57 PM Lars Francke <[email protected]> wrote: > > > Christofer Dutz <[email protected]> schrieb am Di., 11. Aug. 2020, > > 13:22: > > > > > In that case ... > > > > > > how about renaming them to send an email about: "unhandled open issues"? > > > > > > > I'll try to remember to look into it. I think it should be a matter of > > renaming the filter. > > > > And potentially of adjusting the jira workflow to get rid of the triage > > status. I'm okay with changing that as well. > > > > > > > > And what's your opinion on opening commit rights to any Apache committer? > > > > > > > I'm fine with that. > > > > > > Chris > > > > > > Am 11.08.20, 12:13 schrieb "Lars Francke" <[email protected]>: > > > > > > Morning, > > > > > > I can disable the mails if you like. > > > They are just a Jira subscription so things don't get lost if anyone > > > opens > > > a Jira issue. > > > > > > They are unrelated to the committer/review model. > > > Any external person could come in and open an issue about anything we > > > produce and these emails just remind us of such open tickets. > > > > > > Cheers, > > > Lars > > > > > > On Tue, Aug 11, 2020 at 9:21 AM Christofer Dutz < > > > [email protected]> > > > wrote: > > > > > > > Hi folks, > > > > > > > > while I still have the training project on my mind, I still didn’t > > > feel > > > > compelled to re-engage actively. > > > > So I started to observe myself what’s keeping me from doing it. > > > > > > > > For me all these triage needed emails is sort of imply a > > multi-people > > > > approval process (not sure I got it right) > > > > > > > > Could we perhaps disable all the measures we put in place in order > > > to deal > > > > with the high volume of contributions and perhaps even switch to > > > giving all > > > > apache committers commit rights to our repos? > > > > > > > > I think anyone should be allowed to contribute content to trainings > > > … we > > > > could ask people to only change the core-stuff if they are Training > > > > committers. Or we could move the core-stuff into a separate repo … > > > so we’d > > > > have two repos. One which the training committers are allowed to > > > commit to > > > > and a content repo which anyone can contribute to. > > > > > > > > Chris > > > > > > > > > > > > > > > > > > > >
