Re: testing a new process for social media

[Link Dupont]

FWIW, FESCo and other Fedora teams often use Pagure projects to track 
issues. It might be worth seeing how some of those teams sort and 
organize tasks into issues.


https://pagure.io/fesco
https://pagure.io/fedora-marketing

On Sun, Nov 5, 2017 at 6:21 PM, Sriram Ramkrishna  
wrote:



On Sat, Nov 4, 2017 at 9:05 AM Rosanna Yuen  wrote:
Is there documentation/walkthrough as to how this process would 
work? Especially for those of us who have never used gitlab before?


Otherwise this seems like another technical barrier to entry for 
what should be a relatively nontechnical task.


Not yet, as I'm still familiarizing myself with gitlab.  It'll try to 
document something this week and we can poke at it and see if it is 
the right tool.  I'm hesitant to add new tools because it just adds 
more burden to the sysadmin team.  But I think something to track it 
as a ticket I think would be useful than none at all.


sri



On Fri, Nov 3, 2017 at 10:34 PM, Sriram Ramkrishna 
 wrote:

Carlos Soriano was kind enough to create
http://gitab.gnome.org/GNOME/engagement, and so you can now create 
issues for things like we want to advertise.  As a test, I have put 
in November Bug Squash Month - 
https://gitlab.gnome.org/GNOME/engagement/issues/1.


This way we have some way to track the things that need to be done 
and close them out easily when complete.


sri

___
engagement-list mailing list
engagement-list@gnome.org
https://mail.gnome.org/mailman/listinfo/engagement-list





--
Rosanna Yuen
Director of Operations
GNOME Foundation, Inc.


___
engagement-list mailing list
engagement-list@gnome.org
https://mail.gnome.org/mailman/listinfo/engagement-list

Re: [Engagement] Relaying out bug fixes news via social media

[Sriram Ramkrishna]

On Sat, Nov 4, 2017 at 6:00 AM Alexandre Franke  wrote:

> On Fri, Nov 3, 2017 at 6:46 PM, Umang Jain 
> wrote:
> > Hi there,
>
> Hello,
>
> I apologize in advance for sounding like a buzzkill, but I do not
> share the enthusiasm about this. I do agree with the general idea,
> just not the proposed form.
>

That's fine, a good idea should be able to stand up to a challenge
otherwise how would we know it is any good?


> > We have come up with an idea in the area of social media outreach and
> > it would be glad if you can share your views on it. The idea is to
> > relay news out in the social media whenever any bug/issue is fixed via
> > dedicated GNOME Bugs' Social Media Channels (thereafter referred as
> > SMC).
>
> With some curation? Because otherwise I really don’t see any value in
> this and people that want to see everything should just subscribe to
> commits-list.
>

Well, if it was not curated we would create a GNOME Bugs twitter that
people can subscribe to.  We would not use the GNOME account for this at
all as it would be total spam.


> > GNOME Bugs' SMC are not created yet and will be separate from main
> > GNOME handles. You can take a look at LibreOffice's bug channel [1].
> > [1] https://twitter.com/LibreOfficeBugs
>
> That LO channel is noisy. I would take it as an example of what not to aim
> for.
>

Only if you want to subscribe to the LibreOfficeBugs, not necessarily LO.
If that is noisy that is a different issue.


> > Although, based on the severity of the bug/issue, the main GNOME
> > handle can retweet/relay the link on it's own account. The idea is to
> > keep a separate bug SMC is:
> >
> > * Not to make main GNOME handle very noisy
> > * To have automated GNOME bugs SMC
>
> Please don’t make it automatic. That’s a sure way to make it noisy and
> uninteresting.
>

We could add some parameters that might could make it more interesting to
publish.


> > I think that most of us agree that social media is the fastest way to
> > get information out.
>
> Can we also agree that social media are flooded with content and that
> people waste a lot of time on them skimming through it to find
>
>
Sure, we can agree on that as well.

> Therefore, as far as code development is
> > concerned, it takes a while till the information is actually relayed
> > out. Mostly, until someone blogs about it and then pick up by other
> > blogs and so on..
>
> You need to find balance between the current lack of communication and
> the overwhelming flood of an automated feed.
>

I agree, we definitely can discuss this further.


> > We can get fast here and be more verbose about the work that goes into
> > everyday. In addition to that, we want it to be automated; similar to
> > [1]
>
> Again, this is a bad idea.
>
> We did have something that was called the [commit
> digest](https://blogs.gnome.org/commitdigest/), a weekly blog post
> highlighting the most interesting code changes, and it was good.
> That’s what you should aim at. Twitter or blog posts doesn’t really
> matter, but the curation aspect is key to make it good. Unfortunately,
> Frédéric Peters was the only one putting in the time that requires and
> after quite a while he moved to other things.
>

What made it good?  What was the work involved around it?


> > Now comes the most interesting part. It would be really great if we
> > can mention "Newcomers" and their internet handle in the bug SMC link;
> > That should really make them feel special as they can show to the
> > world that they have done something great and brag!
>
> Sure, that is a good idea.
>

How about we do this as the first step then?  That would give the curated
content, and also the ability for newcomers to share something.  It should
address most of your concerns, yes?

sri


>
___
engagement-list mailing list
engagement-list@gnome.org
https://mail.gnome.org/mailman/listinfo/engagement-list

Re: testing a new process for social media

[Sriram Ramkrishna]

On Sat, Nov 4, 2017 at 9:05 AM Rosanna Yuen  wrote:

> Is there documentation/walkthrough as to how this process would work?
> Especially for those of us who have never used gitlab before?
>


> Otherwise this seems like another technical barrier to entry for what
> should be a relatively nontechnical task.
>

Not yet, as I'm still familiarizing myself with gitlab.  It'll try to
document something this week and we can poke at it and see if it is the
right tool.  I'm hesitant to add new tools because it just adds more burden
to the sysadmin team.  But I think something to track it as a ticket I
think would be useful than none at all.

sri


> On Fri, Nov 3, 2017 at 10:34 PM, Sriram Ramkrishna 
> wrote:
>
>> Carlos Soriano was kind enough to create
>> http://gitab.gnome.org/GNOME/engagement, and so you can now create
>> issues for things like we want to advertise.  As a test, I have put in
>> November Bug Squash Month -
>> https://gitlab.gnome.org/GNOME/engagement/issues/1.
>>
>> This way we have some way to track the things that need to be done and
>> close them out easily when complete.
>>
>> sri
>>
>> ___
>> engagement-list mailing list
>> engagement-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/engagement-list
>>
>>
>
>
> --
> Rosanna Yuen
> Director of Operations
> GNOME Foundation, Inc.
>
___
engagement-list mailing list
engagement-list@gnome.org
https://mail.gnome.org/mailman/listinfo/engagement-list

Re: testing a new process for social media

[Sriram Ramkrishna]

On Sat, Nov 4, 2017 at 2:51 AM Alexandre Franke  wrote:

> On Sat, Nov 4, 2017 at 6:34 AM, Sriram Ramkrishna 
> wrote:
> > Carlos Soriano was kind enough to create
> > http://gitab.gnome.org/GNOME/engagement, and so you can now create
> issues
> > for things like we want to advertise.  As a test, I have put in November
> Bug
> > Squash Month - https://gitlab.gnome.org/GNOME/engagement/issues/1.
> >
> > This way we have some way to track the things that need to be done and
> close
> > them out easily when complete.
>
> Cool. How does that work exactly? You seem to imply that we will keep
> a single issue for the whole Bug Squash Month campaign. How do we e.g.
> plan tweets that need to be sent out or track those that have been? An
> issue in a bugtracker is supposed to be a single task and one closes
> it when they’re done with it, which allows progress to be tracked.
>

I'm still learning it myself.  So, my hope is that I can come up with a
solid process where people can put requests in and we can monitor the queue.

There is a TODO setup there, and hopefully that will help.  A process is
better than no process which is what we have right now.  If Gitlab doesn't
work for us then we will find something else that will.

sri


> --
> Alexandre Franke
> GNOME Hacker & Foundation Director
> ___
> engagement-list mailing list
> engagement-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/engagement-list
>
___
engagement-list mailing list
engagement-list@gnome.org
https://mail.gnome.org/mailman/listinfo/engagement-list